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Kunnskap for en bedre verden 


Sammendrag 


Hvert år slippes rundt 2 millioner sauer ut på utmarksbeite i Norge. I løpet av 
beiteperioden som varer i 16 uker for sauer og geiter, går sauene fritt og har mulighet til 
å oppsøke de beste beiteområdene å beite på. Denne perioden er ikke uten fare for 
sauene. Tall fra 2019 viser at 6.5% av lammene og 3.2% av sauene som ble sluppet ut 
på beite det året, ikke returnerte ved sauesankingen til høsten. Det finnes mange 
årsaker til at sauer ikke overlever beiteperioden slik som sykdom, miljøfaktorer eller at 
rovdyr forsyner seg av bestanden. Alle bønder som holder sau på beite, er derfor pålagt 
å følge opp sine dyr mens de befinner seg på utmarksbeite. Bønder som holder dyr på 
utmarksbeite, er berettiget statlig erstatning for sauer tapt til fredet rovvilt over 
beiteperioden. Tapet må dokumenteres ved søknad om erstatning til Miljødirektoratet. 


I dag gjennomføres tilsyn på utmarksbeite i stor grad ved bruk av penn og papir, og det 
benyttes manuelle løsninger som regneark eller permer for samling og lagring av den 
innsamlede dataen. Den innsamlede dataen har ingen fastsatt struktur og det finnes 
ingen standardisert måte å generere rapporter på, for å dokumentere beitesesongen. For 
å forenkle prosessen med å registrere observasjoner på oppsynsturer, strukturere den 
innsamle dataen, forbedre informasjonsflyten i beitelaget og effektivisere 
dokumentasjonsprosessen, ble det utviklet et system bestående av en mobilapplikasjon 
og en webapplikasjon med en felles backend-tjeneste. Denne rapporten beskriver 
designet, utviklingen, testingen og evalueringen av dette systemet og de prosessene som 
er blitt gjennomført i den sammenheng. 


På bakgrunn av innledende samtaler med domeneekspert Svein-Olaf Hvasshovd, ble det 
fastsatt kravspesifikasjoner og mål ved prosjektets start. Basert på dette ble det utviklet 
konseptuelle modeller og flytdiagrammer som la grunnlag for designet av den første 
versjonen av systemet. Systemet ble deretter brukertestet i flere runder og brukernes 
tilbakemeldinger ble inkorporert i løsningen. Under utviklingsperioden ble det i stor grad 
tatt hensyn til ønsket funksjonalitet fra brukerne og den definerte målgruppen, ved valg 
av teknologi og utvikling av systemkomponenter. Utviklingsperioden resulterte i en 
fullstendig løsning som fikk gode tilbakemeldinger fra brukerne ved endelige 
brukertester, og oppnådde gode resultater under sammenligningstester med dagens 
metoder. 


De endelige evalueringene av systemet viser at systemet fungerer mer effektivt enn 
dagens metoder. Systemet tilbyr utfyllende og tilstrekkelig informasjon til brukerne, 
oppfyller brukernes behov svært godt og imøtekommer krav og mål som ble definert ved 
prosjektstart. 


Abstract 


Every year about 2 million sheep are let out to graze in outfield pastures in Norway. 
During the grazing period which lasts for 16 weeks for sheep and goats, the animals 
roam freely and are free to seek out the best grazing areas. This period is however 
dangerous for the animals, and numbers from 2019 suggest that 6.5% of lambs and 
3.2% of sheep that are let out to graze, never return. There are many reasons for sheep 
not surviving the grazing season, like illness, environmental factors and predators. 
Because of this, all farmers who keep sheep in outfield pastures are required to follow up 
on their animals while they are out grazing. These farmers are entitled to compensation 
from the government should their livestock be lost to protected predators during the 
grazing period. These losses must be documented when applying for compoensation from 
Miljødirektoratet. 


Today the registration of events during supervision of sheep is mostly done using pen 
and paper , and manual methods like spreadsheets or folders are used for collecting and 
storing the gathered data. The data collected has no set structure and there is no 
standardised way of generating reports of the completed grazing season for 
documentation purposes. To simplify the process of registering observations while 
performing supervision trips, structure the gathered data, improve the flow of 
information in grazing groups and make the documentation process more effective, å 
system consisting of å mobile application and å webapplication with a common backend 
as åa sevice solution was developed. This report describes the design, development, 
testing and evaluation of this system, and the processes accompanying it. 


Based on the initial conversations with the domain expert, system requirements and 
goals were developed at the start of the project period. On the basis of this, conceptual 
models and flow diagrams were developed which laid the foundation for the design of the 
first iteration of the system. The system was then run through several usability tests and 
the user's points of feedback were implemented. During the development period users 
wishes for functionality as well as the defined user group for the system were taken into 
consideration when selecting technology and development of system components. The 
development period resulted in a fully functioning system that received good feedback 
from users during the final usability tests and achieved good results during the 
comparative tests with the methods used today. 


The final evaluation of the system show that the system works more effectively than the 
methods used today, offers extensive and sufficient information to the users, fulfils user 
needs very well and achieves the requirements and goals that were defined at the start 

of the project. 
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Forord 


Gjennom dette prosjektet er det blitt utviklet et system for å forenkle oppsynet med sau 
[e] - [e) p [e] p 

på utmarksbeite, og for å gjøre det raskere og enklere å dokumentere den gjennomførte 

beitesesongen. Systemet består av en mobilapplikasjon og en webapplikasjon hvor 

mobilapplikasjonen er sentrert rundt informasjonsregistrering og webapplikasjonen tilbyr 

en strukturert oversikt over all registrert data i tillegg til muligheter for å generere 

rapporter. 


Dersom noen ønsker å teste systemet er mobilapplikasjonen blitt lansert på både Google 
play store og Apple app store for intern testing. 


For å teste gjennom Google play send en e-post til: contact.welu&gmail.com. 
For å teste via app store følg lenken: https://testflight.apple.com/join/Ubq2STUR 
Webapplikasjonen er tilgjengelig på: https://beiteweb.herokuapp.com 
Testbruker for systemet er: beitemaster.testØgmail.com 

Passord: tester123 


Vi gjør oppmerksom på at data som blir lastet opp til websiden kan være tilgjengelig for 
andre medlemmer av gruppene man deltar i. Det er derimot valgfritt å laste opp 
informasjon fra mobilapplikasjonen og all data som registreres vil være privat på 
telefonen frem til dette er gjort. 


Vi ønsker å rette en takk til vår veileder og domeneekspert Svein Olaf Hvasshovd i tillegg 
til alle som har deltatt som brukertestere av systemet og dermed har bidratt i stor grad 
til utformingen av den endelige løsningen. 
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1 Introduksjon 


1.1 Aktører 


1.1.1 Utviklingsteam 

Gjennom oppgaven vil det bli referert til Teamet. Teamet består av to studenter ved 
studieprogram Datateknologi ved NTNU. Begge studentene er tatt opp ved 
studieretningen programvaresystemer. 


1.1.2 Intern veileder og produkteier 

Veileder for dette prosjektet ved NTNU har vært Svein-Olaf Hvasshovd, professor ved 
Institutt for datateknologi og informatikk. Professor Hvasshovd har inngående kjentskap 
til domenet gjennom lang erfaring med bistand til bønder som driver sauedrift på 
utmarksbeite, i tillegg til lang erfaring med veiledning av oppgaver innenfor samme felt. 
Han vil derfor være hovedkilden til oppgavens domenekunnskap med respekt til 
bøndenes opplevelser, problemer og utfordringer per dags dato. 


På bakgrunn av at dette prosjektet er gjennomført som et selvstendig prosjekt vil 
professor Hvasshovd også inneha rollen som produkteier for systemet. 


1.2 Motivasjon 


Hvert år slippes rundt 2 millioner sauer ut på utmarksbeite i Norge (Mattilsynet, 2020). I 
løpet av beiteperioden som varer i 16 uker for sauer og geiter (Norges Bondelag), går 
sauene fritt og har mulighet til å oppsøke de beste beiteområdene å beite på. Denne 
perioden er ikke uten fare for sauene. Tall fra 2019 viser at 6.5% av lammene og 3.2% 
av sauene som ble sluppet ut på beite det året, ikke returnerte ved sauesankingen til 
høsten (Mattilsynet, 2020). Det finnes mange årsaker til at sauer ikke overlever 
beiteperioden slik som sykdom, miljøfaktorer eller at rovdyr forsyner seg av bestanden 
(Dyrebeskyttelsen Norge). Alle bønder som holder sau på beite er pålagt oppfølging av 
sine dyr, mens de befinner seg på utmarksbeite (Forskrift om velferd for småfe, 2005). 
Bønder som holder dyr på utmarksbeite er berettiget statlig erstatning for sauer tapt til 
fredet rovvilt over beiteperioden (Forskrift om rovvilterstatning for husdyr, 2014). 
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For å være berettiget erstatning må bonden sende inn søknad til Miljødirektoratet etter 
endt beitesesong hvor han/hun dokumenterer sin flokk og hvilke tap de har hatt gjennom 
sesongen (Miljødirektoratet, 2021a). Bondelaget anbefaler å i stor grad benytte seg av 
vedlegg i denne søknaden, for å belyse aspekter ved beitesesongen som ikke blir direkte 
dokumentert gjennom Miljødirektoratets søknadsskjema (Norges Bondelag, 2020). Dette 
inkluderer forhold som observasjoner av rovvilt, dokumentasjon av tap, dokumentasjon 
på at oppsyn med sauen er blitt utført og hvordan oppsynet er utført. Det er ingen 
standard for hvordan et slikt vedlegg ser ut og de aller fleste bønder og beitelag benytter 
seg per i dag av papir og blyant for registrering av sauer når oppsyn blir gjennomført. 


Denne oppgaven har som formål å presentere utviklingen, testingen og evalueringen av 
et nytt system for registrering av oppsyn med sau på beite, med hovedmål om å forenkle 
prosessen for oppsynspersoner som registrerer sine turer, sentralisere informasjonsflyten 
i beitelag og gjøre det enklere å produsere rapporter basert på beitesesongens 
hendelser. 


1.3 Målgrupper 


- — Bønder som driver sauedrift og har sau på utmarksbeite 
- — Oppsynspersoner som støtter bønder ved å gå oppsynsrunder på beiteområde 
- Ledere i beitelag 


1.3.1 Tall på potensielle brukere 
På bakgrunn av de definerte målgruppene for prosjektet, kan det grovt estimeres hvor 
mange potensielle brukere applikasjonen har. 


Antall gårder med sauer på utmarksbeite 


I følge tall fra SSB var det i 2020, 17 931 jordbruksbedrifter med husdyr på utmarksbeite 
(SSB, 2021). Husdyr er her ikke begrenset til sau, men inkluderer storfe, geiter, hester 
og tamrein. Norges bondelag opplyser at i 2021 var det ifølge Landbruksdirektoratets 
data ca 12 000 jordbruksfortak som søkte om produksjonstilskudd for sau sluppet på 
utmarksbeite (Larsen, 2021). Basert på disse tallene kan man estimere at antallet gårder 
som har sau på utmarksbeite ligger et sted mellom 12 000 og 18 000. 


Antall beitelag med sauer på utmarksbeite 


I følge det Norske bondelaget finnes det ingen konkrete tall på hvor mange beitelag det 
finnes i Norge per i dag (Larsen, 2021), men ifølge Norsk institutt for bioøkonomi 
(NIBIO) er ca 74% av sau på utmarksbeite i Norge per 2021 organisert i organisert 
beitebruk (NIBIO, 2021). 


Estimering av brukergruppe 


Med utgangspunkt i samtaler med professor Svein-Olaf Hvasshovd er det grunn for å tro 
at hver gård har minst en bonde eller oppsynsperson knyttet til seg, i mange tilfeller 
flere. For denne estimeringens del, har det blitt tatt utgangspunkt i at det per gård finnes 
mellom en og tre oppsynspersoner. Med bakgrunn i tallene presentert ovenfor og disse 
opplysningene estimeres det dermed at brukergruppen for systemet utviklet i forbindelse 
med denne oppgaven ligger et sted mellom 12 000 og 54 000 personer. 
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1.4 Mål for prosjektet 


Det overordnede målet for prosjektet er utviklingen av et system som ved hjelp av en 
mobilapplikasjon og en web applikasjon forenkler prosessen med tilsyn av sau på 
utmarksbeite, sentraliserer beitelagets dataflyt og gjør det enklere å produsere rapporter 
for Miljødirektoratet ved beitesesongens slutt. 


De underordnede konkretiserte målene beskrevet i denne seksjonen er kategorisert som 
effektmål og resultatmål. 


1.4.1 Effektmål 
- — Enklere og raskere å notere observasjoner under en oppsynstur 
- — Enklere å registrere oppsynsturer gjennomført 
- — Forenkle og effektivisere rapportgenereringsprosessen for innsending til 
Miljødirektoratet 
- — Enklere å holde oversikt over beitelagets felles data og sine egne sauer og tapstall 


Systemet har som hovedmål å forenkle dokumentering av beitesesongens hendelser ved 
å tilby en strukturert og effektiv måte å registrere oppsynsturer på, i tillegg til å forenkle 
prosessen rundt generering av rapporter. Ved å sentralisere informasjonen i beitelaget 
slik at alle har tilgang til den samme dataen gjennom hele sesongen uten ekstra 
distribusjonsarbeid, vil dataflyten i beitelaget bli bedre og hver bonde vil ha kontroll over 
sin data til enhver tid. 


Gjennom prosjektet har det vært et fokusområde å gjøre brukertester ved alle 
iterasjoner av produktet for å sikre et så brukervennlig resultat som mulig. 


1.4.2 Resultatmål 
- — Mobilapplikasjonens funksjonalitet i henhold til tabell under 
- —Webapplikasjonens funksjonalitet i henhold til tabell under 
- Systemet er tilgjengelig for alle i målgruppen 
- Systemet tilfredsstiller gjeldende krav til GDPR i henhold til gjeldende lovgivning 


Prosjektet har hatt som mål å resultere i et funksjonelt system som er enkelt å bruke for 
alle brukere i målgruppen. Systemet skulle inkludere en registreringsløsning for 
oppsynsturer, oversikt over beitelag og data og rapportgenerering for 
erstatningssøknader. Tabellene under presenterer resultatmålene for mobil og 
webapplikasjonen respektivt, gruppert med utgangspunkt i hvilken funksjonalitet de 
tilhører. 
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Mobilapplikasjon 


Funksjonalitet 


[-] 


Mal 


Opprette profil 


- En bruker skal kunne opprette en 
profil for å benytte systemet 


Logge inn 


- En bruker med profil skal kunne 
aksessere systemet med sin epost 
og passord 


Profil 


- En bruker skal kunne slette sin 
profil 

- En bruker skal kunne endre sin 
profilinformasjon 


Feed 


- En bruker skal kunne se de nyeste 
turene som er blitt gjennomført 

- En bruker skal kunne aksessere 
eldre turer og se detaljer om turen 


Beitegrupper 


- En bruker skal kunne opprette ny 
beitegruppe 

- En bruker skal kunne opprette 
gårder i beitegruppen 

- En bruker skal kunne legge til 
medlemmer i gruppen 

- En bruker skal kunne godta en 
invitasjon til en beitegruppe 

- En bruker skal kunne aksessere 
sine beitegrupper og se turer 
gjennomført i gruppen 

- En bruker skal kunne administrere 
gruppen om brukeren er 
administrator 


Oppsynstur 


- En bruker skal kunne starte en ny 
oppsynstur 

- En bruker skal kunne laste ned et 
kartutsnitt for bruk uten internett 

- En bruker skal kunne registrere 
flokker sett med passende 
detaljnivå basert på hvor mye 
brukeren ser 

- En bruker skal kunne registrere 
hendelser på en oppsynstur slik 
som syn av rovdyr 

- En bruker skal kunne se en 
oversikt over turen når turen er 
gjennomført 


Tabell 1.1: Resultatmål for mobilapplikasjonen 
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Webapplikasjon 
Funksjonalitet Mål 
Opprette profil - En bruker skal kunne opprette en profil for å benytte 
systemet 
Logge inn - En bruker med profil skal kunne aksessere systemet med 
sin epost og passord 
Profil - En bruker skal kunne slette sin profil 
- En bruker skal kunne endre sin profilinformasjon 
Se oppsynstur - En bruker skal kunne se detaljer om turen etter fullført tur 
- En bruker skal kunne se beitekvaliteten i beiteområdet i 
kartet 
Generere rapport - En bruker skal kunne generere rapporter basert på 
beitesesongen i standardisert format 


Tabell 1.2: Resultatmål for webapplikasjonen 


1.5 Kort produktbeskrivelse 


Systemet som er utviklet vil tilby oppsynspersoner, bønder og beitelagsansvarlige en 
enklere og mer effektiv måte å registrere hendelser og observasjoner under 
gjennomføring av oppsynsturer på utmarksbeite. Systemet vil også forbedre muligheten 
for kontinuerlig tilgang til data om gårdens sauer, tap og andre observerte hendelser 
gjennom sesongen, i tillegg til loggføring av når turer har blitt gjennomført og hvem som 
har gjennomført turene. Ved sesongens slutt vil bønder kunne gå inn på en webside for å 
generere en sesongrapport på standardisert format som skal kunne vedlegges eventuelle 
søknader om erstatning for tap til Miljødirektoratet. 


«4 Hedmarksgjengen 
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Mons Arnesen Dashbord 
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Figur 1.1: Bilde av web og mobilapplikasjonen 
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2 Forskningsmetodikk 
2.1 Mål og problemstilling 


Målet med prosjektet er å utvikle et system som kan effektivisere registrering av data på 
oppsynsturer, sentralisere dataflyten i beitelaget i tillegg til å effektivisere og strukturere 
rapporter fra beitesesongen. På bakgrunn av denne målformuleringen har fire 
forskningsspørsmål blitt utarbeidet for å evaluere systemets måloppnåelse og 
effektivitet: 


F1: Hvor mye mer effektivt er det å registrere observasjoner ved hjelp av Beitemaster 
i motsetning til med dagens metoder? 


F2: Hvor presis, detaljert og tilstrekkelig er informasjonen registrert ved hjelp av 
Beitemaster sammenliknet med dagens metoder? 


F3: Hvor mye mer effektivt er det å produsere rapporter ved hjelp av Beitemaster i 
motsetning til ved tradisjonelle metoder? 


F4: Hvor godt dekker Beitemaster brukernes behov når det kommer til oppfølging av 
sau på utmarksbeite? 


Besvarelsen av forskningsspørsmålene over vil bidra til å evaluere systemets effektivitet 
og måloppnåelse og legge grunnlag for videre arbeid med systemet og kartlegging av 
forbedringspotensialer på området. 


2.2 Metode 


Prosjektet har blitt utført i flere faser hvor første fase har bestått av innhenting av 
informasjon om dagens situasjon. Denne fasen var kritisk for å muliggjøre besvarelse av 
forskningsspørsmålene og å legge grunnlag for å utarbeide kravspesifikasjoner og 
designspesifikasjoner for systemet. Informasjonsinnhentingsfasen bestod hovedsakelig 
av intervjuer med personer med kjennskap til dagens praksis med sau på utmarksbeite, 
undersøkelser av eksisterende løsninger, undersøkelser av regelverk, og standarder og 
anbefalinger i relasjon til erstatning av tapt sau. Detaljer om informasjonsinnhentingen 
og funn gjort i denne fasen vil bli videre presentert i avsnittet «Bakgrunn». 


Basert på opplevelsene, beskrivelsene og informasjonen innhentet i denne første fasen 
ble målet og problemstillingen for prosjektet fastsatt. Det ble teoretisert at utviklingen av 
et system for å strukturere måten data samles, lagres og genereres på, kunne løse en 
del av de utfordringene som ble identifisert ved dagens løsninger. Figur 2.1 viser en 
oversikt over den valgte fremgangsmåten og strategien for prosjektet i tillegg til valgt 
datagenereringsmetode. Strategien som ble tatt i bruk var «Design og skapelse» hvor 
utviklingen av systemet var hovedfokuset i prosjektet. Bakgrunnen for valget av denne 
strategien var at ettersom prosjektet ville resultere i et nytt produkt som ikke eksisterer 
per i dag, vil systemet i seg selv i tillegg til besvarelsen av forskningsspørsmålene 
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fremme kunnskapen på området og kunne legge grunnlag for videre utvikling (Oates, 
2006). 


Strategies Data generation 
Data 


methods 
Survey 
= ae 
å analysis 
creation 
G Quantitative 
ll 1 Observation 
| Experiment | : 
l i 
Conceptual p EN == 
framework Case study Question- 
—— —— nl naires Qualitative | 


Literature 
| review 


 ——— 
Action i ===" 
research | 

Ethnography | sia 


Figur 2.1: Illustrasjon av forskningsmetode brukt i prosjektet (Oates, 2006) 


Gjennom utviklingsfasen ble systemet designet, testet og implementert i flere runder 
med fokus på tilbakemeldinger fra brukere. Gjennom testene som ble gjennomført, ble 
både observasjoner og strukturerte intervjuer benyttet for datainnsamling. 


Brukertesting ble først gjennomført etter design av et «proof of concept» ved hjelp av en 
papirprototype, hvor brukerne fikk teste generell funksjonalitet og struktur i 
applikasjonen. 


Neste brukertest ble gjennomført med en interaktiv prototype laget ved hjelp av Figma 
(Figma) hvor brukernes tilbakemeldinger fra forrige test hadde blitt vektlagt. 
Hovedfokuset for denne testen var brukerens opplevelse av struktur, funksjonalitet, og 
generell opplevelse av design og flyt i applikasjonen. 


Basert på brukernes videre tilbakemeldinger på Figma prototypen ble utviklingen av 
applikasjonen startet. Den endelige og fullstendige løsningen ble brukertestet ved slutten 
av prosjektperioden og den innsamlede dataen la grunnlaget for besvarelse av de 
definerte forskningsspørsmålene. Figur 2.2 viser prosjektets utviklingsfaser og 
gjennomførte brukertester. Brukertestene beskrives i større detalj i avsnittet 
«Brukertesting av utforming av design» og evalueringen av systemet utdypes nærmere i 
avsnittet «Resultater». 


Proof of concept Test Figma prototype Test Applikasjon > Test 


Figur 2.2: Testrekkefølge for prosjektet 
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3 Bakgrunn 


3.1 Dagens situasjon 


Når sauer slippes på beite ved starten av beitesesongen, har bøndene ansvar for å følge 
opp dyrene sine regelmessig og dokumentere oppsynet de gjør. Historisk har oppsyn og 
oppfølging av sau på utmarksbeite vært utført av gjetere med spesialkompetanse på 
akkurat dette. Slik gjetepraksis har i stor grad blitt avviklet i Norge med bakgrunn i 
økende krav til effektivisering av landbruk, strengere arbeidsmiljøkrav og en lav 
rovviltbestand (Hind, 2018). På tross av at gjeterne er så godt som forsvunnet, er det 
nedfelt krav i lovverket om oppfølging av dyrene på beite for å sikre best mulig 
dyrevelferd og færrest mulige tap gjennom sesongen. Årsakene til tap av sau på 
utmarksbeite kan være mange, men de mest vanlige årsakene er sykdom, ulykker og 
rovvilt (Landbruksdirektoratet). 


I henhold til loven er det dyreholderens ansvar å sikre så godt som mulig at beitedyrene 
er beskyttet mot rovdyr og unødige påkjenninger i beiteperioden 
(Landbruksdirektoratet). Det finnes i dag flere skadeforebyggende tiltak som kan 
benyttes, gjerne i kombinasjon, for å så godt som mulig sikre sine dyr mot tap til rovvilt. 
Rovviltgjerder som inngjerder beiteområdene for å holde rovdyr ute, eller radiosporing av 
søyer for å monitorere aktivitet og posisjon er slike alternativer (Hind, 2018). Dessverre 
medfører slike tiltak ofte store utgifter for bøndene og selv om det er etablert offentlige 
støtteordninger for delfinansiering, kreves det likevel oppsyn og vedlikehold (Hind, 
2018). På tross av forebyggende tiltak taper bønder sauer til rovvilt hvert år, og de 
hardest rammede besetningene kan i verste fall bli halvert, noe som i ytterste 
konsekvens kan bety slutt på videre drift (Hind, 2018). 


Ettersom Stortinget har besluttet at det skal være forekomst av en rekke rovvilt i Norsk 
natur og at bestanden skal være av en viss størrelse, er det etablert erstatningsordninger 
for Norske bønder som taper sau til rovvilt (Landbruksdirektoratet). Dette innebærer at 
bonden kan få full erstatning for de dyrene som er blitt felt av fredet rovvilt, noe som 
gjør dokumentasjon av beiteperioden svært viktig. 


3.1.1 Oppsyn og kompensasjon for tapt sau 

Bønder kan være berettiget erstatning for sine beitedyr, om de kan påvises å være tatt 
av rovvilt over perioden de er på beite. Likevel er det visse kriterier en bonde må 
overholde om han/hun skal ha rett på erstatning i tillegg til å måtte fremme sitt 
erstatningskrav innen 1. november hvert kalenderår. Noen av kriteriene som må 
oppfylles for å ha rett på slik erstatning er (Forskrift om rovvilterstatning for husdyr, 
2014): 


- —«Dyreeier har handlet aktsomt og har gjort det som med rimelighet kan forventes 
for å avverge eller redusere tap, vurdert i forhold til de verdier som står på spill 
og den foreliggende risiko.» 

- —«Dyreholdet i besetningen er i samsvar med lov 19. juni 2009 nr. 97 om 
dyrevelferd og forskrifter til loven.» 
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- —«Dyreeier har bidratt til at tap oppdages så tidlig som mulig. Straks et taps- eller 
skadetilfelle oppdages skal det gis melding til Statens naturoppsyn for vurdering 
av årsak.» 

- —«dyreeier har gitt riktige og nødvendige opplysninger for å underbygge kravet om 
erstatning. Dette innebærer besetningsdata på individnivå, herunder data over 
tapte og skadde dyr. Dersom dyreeier har gitt fullstendige besetningsdata til 
sauekontrollen, og har samtykket i bruk av besetningsdata fra denne, anses dette 
kravet som oppfylt» 


Et av kravene som skal overholdes for å sikre tilstrekkelig dyrevelferd i beiteperioden er 
periodisk tilsyn av dyrene spesifisert til minst en gang i uken (Forskrift om velferd for 
småfe, 2005). For å dekke dette kravet tilstrekkelig er det vanlig at flere gårder går 
sammen og danner beitelag, hvor de deretter rullerer på hvem det er som går 
oppsynsrunder og ser etter sauene. Oppsynspersonen går en tur i en utvalgt del av 
beiteområdet, noterer antall sauer sett, hvilken tilstand de er i, om antall lam i flokken 
stemmer med markering på søyene og hvilken gård sauene tilhører. Om en bonde 
mistenker at dyr har blitt tatt av rovvilt må eventuelle spor og andre funn dokumenteres, 
de andre i gruppen må informeres og Statens naturoppsyn (SNO), som er 
Miljødirektoratets feltorgan, må varsles (Norges Bondelag, 2020). 


Når tap mistenkes, er det viktig at funn av eventuelle kropper eller andre deler av døde 
dyr blir nøye registrert. Dette inkluderer hvor det ble gjort funn, hvilken tilstand funnene 
er i, miljøfaktorer på stedet, bilder av funnområdet og annen metadata slik som tid og 
dato (Norges Bondelag, 2020). Når SNO varsles om funn av døde dyr som mistenkes 
drept av rovvilt, vil de utføre en evaluering av funnene. Enten ved å sende ut en 
delegasjon for videre undersøkelser eller ved å kontakte bonden direkte for registrering 
av opplysninger. De vil deretter konkludere med sannsynligheten for at dyret er drept av 
rovvilt og dermed om erstatning er berettiget i henhold til loven (Miljødirektoratet). I de 
fleste tilfeller vil man ikke finne rester av døde sau om rovvilt står ansvarlig for deres død 
(Norges Bondelag, 2020). I tilfeller hvor ingen funn er tilgjengelige, vil SNO derfor 
konkludere på grunnlag av sannsynlighet ved oppfyllelse av faste kriterier (Forskrift om 
rovvilterstatning for husdyr, 2014). 


Om bonden ønsker å søke om kompensasjon på bakgrunn av tapte dyr til beskyttet 
rovvilt må en søknad om dette sendes til Miljødirektoratet (Miljødirektoratet, 20214). 
Søknadsprosessen foregår gjennom innsending av et skjema hvor bondens flokk, 
beiteområde og deres tap gjennom beitesesongen dokumenteres. Norges bondelag 
anbefaler at vedlegg brukes hyppig i søknaden, for dokumentasjon av aspekter som kan 
bidra til et riktigere bilde av bondens situasjon (Norges Bondelag, 2020). Dette 
inkluderer blant annet dokumentasjon av: 


- Observasjoner av beskyttet rovvilt i beiteområdet. 

- Rapporter fra SNO. 

- — Privat dokumentasjon av tap, skulle SNOs rapport være resultatløs. 
- — Hvordan timer med oppsyn er kalkulert. 

- Hvordan oppsynet har blitt utført. 


Videre anbefaler Norges bondelag at alle beitelag dokumenterer deres gjennomførte 
oppsynsturer for å kunne bevise at oppsyn er gjennomført i henhold til loven og stille 
bedre i en erstatningssak (Norges Bondelag, 2020). 
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3.1.2 Skadeomfang 

I 2021 ble det utbetalt erstatning for 16 864 sauer tapt til fredet rovvilt i Norge, dette 
tilsvarer en total sum på 43 921 831 kr (Miljødirektoratet, 2021b). Disse tallene har vært 
relativt stabile de siste fem årene, selv om man har sett en liten oppgang i tilfeller fra 
2020 som var et rekordlavt år for tap til rovvilt (Miljødirektoratet, 2021a). Tapsraten i 
dag ligger på cirka halvparten av det den gjorde for 10 år siden, som antas å kunne 
begrunnes med forskyving av beitesesongen for å unngå den verste viltsesongen, pluss 
andre forebyggende tiltak fra bønder og myndigheter (Miljødirektoratet, 2021a). Figuren 
under viser at Jerv og Gaupe er de største truslene mot sauer på utmarksbeite per i dag. 


Sau erstattet per rovdyrstype 


Kongeørn 
10% 
Ulv 
5% 


Ukjent 
9% 


Figur 3.1: Prosentfordeling av erstattet sau drept av rovvilt (Miljødirektoratet, 2021b) 


3.1.3 Merking av sau 

Mattilsynet krever at all sau på beite skal merkes med et visuelt og elektronisk merke i 
begge ører for å indikere opprinnelse (Mattilsynet). Fargen på øremerket er ofte distinkt 
for hver gård i et beitelag og kan benyttes som identifikator på korte avstander for å 
identifisere hvilken gård en sau tilhører (Hvasshovd, 2021). Det er valgfritt hvilken farge 
bøndene bruker på sine merker så lenge de ikke er lakserosa eller hvite (Mattilsynet). 
Øremerket inneholder informasjon som dyreholdets id nummer og individnummer på 
dyret for videre identifisering (Mattilsynet). 
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Figur 3.2: Lam med øremerker (OsID) 


Slips benyttes for å markere hvor mange lam en søye ble sluppet på beite med ved 
beitesesongens start (Hvasshovd, 2021). Ved hjelp av slips kan oppsynspersoner enkelt 
identifisere hvor mange lam som burde følge med den observerte søya. Det finnes 
etablerte anbefalinger for hvilke farger som bør benyttes for forskjellige antall lam 
(NSG). NSGs anbefalinger for fargekoding på slips hos søyer er: 


- 0 Lam: Rød 
- 1 Lam: Blå 
- 2Lam: Gul 
- 3 Lam: Grønn 


Figur 3.3: Søye med slips og øremerke (OsID) 


3.1.4 Dagens oppsynsrutiner 

I henhold til loven gjennomføres oppsyn med sauen per i dag minst en gang i uken og 
ansvaret fordeles mellom gårdene som deltar beitelaget. Men selv om ansvaret tilfaller 
en spesifikk gård er det ikke nødvendigvis slik at det er bonden selv som går 
oppsynsturen med dyrene. Mange gårder har ansatte eller hjelpere utenfra som bidrar 
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med å gå oppsynstur på beite for å lette bondens arbeidsmengde (Hvasshovd, 2021). På 
grunn av denne ordningen er det ikke alltid et fast antall mennesker som bidrar med 
oppsynet per sesong, som kan skape utfordringer om notatene fra turen ikke er godt 
skrevet. 


Når en tur gjennomføres er det viktig å notere observasjoner underveis slik at man kan 
dokumentere dem i ettertid. Dette er viktig både i erstatningssaker, tilsynssaker og for 
bøndenes egen oversikt gjennom sesongen. Den tradisjonelle måten å notere slike 
observasjoner på er med penn og papir (Hvasshovd, 2021). De fleste velger å benytte 
seg av notisbøker, og NSG har utarbeidet både spesifiserte notisbøker og 
standardskjemaer i et forsøk på å gjøre notatene mer strukturert (NSG). 
Hovedproblemet med slik notatføring blir klart så snart himmelen fylles med regnskyer. Å 
notere på papir i regnvær er en utfordring som ikke er lett løselig på annen måte enn å 
bytte noteringsmedium. 


Et annet relevant problem er organiseringen av notatene i etterkant av gjennomført tur. 
Er notatene skrevet ned i en notatbok må de overføres til et annet medium for 
oppbevaring på et felles sted. NSGs standardskjemaer kan samles i en fellesperm, 
scannes inn på PC eller dataen kan overføres til NSGs Excel mal (NSG). Etter at 
Miljødirektoratet opprettet elektronisk søknad for erstatning av beitedyr har behovet for 
notatføring på datamaskin økt betydelig og det krever derfor mer tid av bonden som blir 
nødt til å overføre informasjonen fra ark eller notater (Hvasshovd, 2021). Generering av 
rapporter for slike søknader er også en tidkrevende prosess om man ikke har strukturert 
oppsynsdataen jevnlig gjennom sesongen. 


Kommunikasjonen rundt oppsynsturene foregår per i dag i stor grad muntlig, både når 
det gjelder planlegging, gjennomføring og observasjoner. Når en oppsynsperson 
observerer noe utenom det vanlige vil ikke de andre i beitelaget vite om dette før de blir 
varslet muntlig av bonden som hadde ansvar for oppsynsrunden. Det er også en 
utfordring for hver enkelt bonde å holde oversikt over de gjennomførte observasjonene 
gjennom sesongen og hvor sauene sist ble sett, som kan være svært relevant når man 
planlegger ruten man skal gå (Hvasshovd, 2021). 


3.2 Eksisterende løsninger 


I denne seksjonen er det beskrevet noen eksisterende løsninger for effektivisering av 
oppsyn med sau på beite i tillegg til sanking av sau ved sesongens slutt. 


3.2.1 Findmy 

Findmy er en tjeneste som leverer et elektronisk halsbånd de kaller E-bjelle. Suene går 
med E-bjellen rundt halsen og er dermed utstyrt med GPS-sporing som sammen med 
varslingssystemer og en mobilapplikasjon med kart og monitoreringsverktøy gir bonden 
bedre oversikt over dyrene (Findmy). E-bjella er en batteridrevet enhet som sender 
signaler på tidsbestemte intervaller med posisjon og status på dyret og er utstyrt med 
Bluetooth som gjør det mulig å tilkoble og finne dyret ved tilsyn og sanking med bruk av 
mobilen (Findmy). Tjenesten leverer også løsning for Geofence (Et geografisk avgrenset 
område som defineres digitalt, ikke et fysisk avgrenset område) slik at brukeren får 
beskjed med en gang et dyr er på vei ut av det registrerte området (Findmy). 
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Findmy benytter seg av satellitter for å oppnå best mulig dekning og har i dag dekning i 
hele Norge så lenge sauen er under himmelen og ikke befinner seg under berghyller eller 
liknende som blokkerer signalet (Findmy). Det opplyses likevel at forskjellig topologi kan 
påvirke bjellenes sendeforhold i diverse områder. Findmy anbefaler at man sporer minst 
25% av saueflokken og opp mot 100% for å oppnå best resultat. Hver bjelle koster 
1980,- uten moms (Findmy). 


3.2.2 Telespor 

Telespor er en tjeneste for elektronisk overvåkning av husdyr på beite som benytter seg 
av radiobjelle som festes på dyret. Enheten er utstyrt med GPS og bevegelsessensor som 
med forhåndsdefinerte tidsintervaller sender oppdatert data til telespor. Målet med 
løsningen er å la bonden se hvor dyrene befinner seg i kartet og sende ham/henne sms- 
varslinger når diverse alarmer utløses (Telespor). Slike alarmer kan inkludere at dyret 
ikke har beveget seg på flere timer, har oppholdt seg på samme sted over lengre tid eller 
bjella ikke har kunnet rapportere innen en gitt tid (Telespor). 


Telespor er en abonnementsbasert tjeneste hvor man kjøper bjellen til 989,- og deretter 
abonnerer på tjenesten for mellom 99,- og 119,- for 5 måneders bruk i året. I tillegg er 
man etter hver sesong nødt til å bytte batteri i bjellene. Et batteri koster mellom 65,- og 
75,- og en bjelle har en forventet levetid på 5 år (Telespor). Telespors løsning benytter 
seg av Norgeskarts applikasjon for å visualisere individer i kart, en tjeneste som koster 
50,- i året (Telespor, 2022). Ettersom Telespors løsning baserer seg på mobiltjenester for 
å rapportere er det risiko for at sau beveger seg utenfor dekningsområde og at bonden 
ikke vil få rapporter om dyrets status før den beveger seg inn i dekket område igjen. Det 
kan også være utfordringer med rapportering om dyret befinner seg i nærheten av en 
fjellvegg eller liknende (Telespor, 2022). 


3.2.3 Nofence 

Nofence sitt produkt baserer seg på virtuelle innhegninger definert av brukeren som 
definerer hvilke områder dyrene kan bevege seg i. For å få dyrene til å holde seg 
innenfor de oppmerkede områdene i kartet, utstyres dyrene med en klave som lager lyd 
når dyret er på vei ut av området. Løsningen krever derfor at dyrene læres opp til å 
forstå hvordan de skal håndtere lyden slik at dyrene beveger seg inn i rett område igjen 
om de skulle høre lyden (Nofence). Nofence leverer mobilapplikasjoner til både Android 
og Apple hvor systemet kan administreres og dyrene kan overvåkes (Nofence). 


Nofence sier at på bakgrunn av dyrevelferd skal alle voksne dyr i flokken være utstyrt 
med klave (Nofence). Løsningen er abonnementsbasert og har en pris på 799,- i året om 
man benytter mellom 1 og 9 klaver. Over dette kan man benytte en fastpris på 640,- 
pluss moms per år eller variabel pris på 149,- pluss 3,- per beitedøgn. Alle priser er uten 
moms (Nofence). Kommunikasjon med klaven skjer via mobilnettet og det anbefales å 
ha mobildekning i hele beiteområdet (Nofence). 


3.2.4 Smartbjella 

Smartbjella tilbyr en smartbjelle som henges på dyret, registrerer dyrets posisjon via 
GPS og sender oppdatert informasjon til Smartbjella. Informasjonen som genereres kan 
observeres av brukeren via en webapplikasjon som viser hvor dyrene befinner seg i 
kartet og historisk forflytning av flokkene. Smartbjella tilbyr også dødsvarsel, Geofence 
og tidsalarmer som gir brukeren varslinger når dyr har vært stillestående over en lengre 
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periode, beveger seg utenfor et bestemt område eller et dyr skal ha spesiell oppfølging 
som for eksempel vaksine (Smartbjella; Smartbjella). 


Smartbjella benytter seg av mobilnettet for sending av signaler som dermed medfører at 
signaler ikke vil sendes fra dyret så lenge det er utenfor mobilnettets dekning. Det kan 
også medføre problemer for sending av data om sauen ikke oppholder seg under åpen 
himmel (Smartbjella, 2022). Smartbjella koster 999,- per enhet og er en 
abonnementsbasert tjeneste med flere planer som gir mer eller mindre data om dyrene. 
Den billigste planen koster 109,- i året per bjelle mens den dyreste koster 149,- med et 
minimumskvantum på 10 enheter (Smartbjella). 


3.2.5 Beitesnap 

Beitesnap er et registrerings- og oppsynsverktøy for dokumentering av dyr på beite og 
virker som et notifikasjonssystem mellom turgåere og dyreeiere. Verktøyet består av en 
mobilapplikasjon som er tilgjengelig i både Apple app store og Google play. For turgåere 
er hensikten at de skal kunne registrere observasjoner av dyr på beite mens de er ute og 
går tur. En registrering gir informasjon om posisjonen og tilstanden til et dyr. Denne 
informasjonen vil bli direkte tilgjengelig for dyreeier og legges til i historikken for 
beitesesongen. Mobilapplikasjonen fungerer også som et registreringssystem for 
dyreeiere som kan definere beiteområde i kart og registrere hendelser på beite og tilsyn 
med dyrene. Løsningen leverer også funksjonalitet for generering av ferdige rapporter 
som dokumentasjon på tilsyn gjennom en beitesesong (Beitesnap). 


Beitesnaps løsning koster 1200,- uten moms per produsent i året. Dette lar produsenten 
ha 7 underbrukere. Bruk for turgåere er gratis (Beitesnap). For beitelag som handler 
sammen kan brukerne få opp mot 50% rabatt. Applikasjonen fungerer offline for 
områder som ikke har mobildekning (Beitesnap). Beitesnap ser ikke lenger ut til å være i 
drift da nettsiden deres ikke er oppdatert siden 2019, applikasjonen ikke finnes i Google 
play store og applikasjonen i Apple App store ikke lenger lar deg logge inn. 


3.2.6 Sammendrag 

Flere av tjenestene som leveres i dag forenkler og effektiviserer oppfølging av dyr på 
beite gjennom sporing, varsling og registrering av avvik ved at bøndene har direkte 
oppdateringer og oversikt over dyrene tilgjengelig på internett. Alle sporingsløsningene 
nevnt i denne seksjonen benytter seg av mobilnett for rapportering av data fra dyrene. 
Dette gjør at beiteområdene er nødt til å ha god GPS- og tele-dekning for at løsningene 
skal fungere godt. Unntaket fra dette er Beitesnap som er mer rettet mot fysisk tilsyn og 
manuell registrering, men systemet virker ikke til å være operativt. 


I tillegg til kravet om teledekning i hele beiteområdet er flere av løsningene dyre og 
krever investeringer fra bonden for å ta dem i bruk. Tabellen nedenfor viser en oversikt 
over estimerte kostnader per system for investering i én enhet. Flere av systemene gir 
muligheter for at flere brukere benytter systemet til samme pris, dette er ikke tatt 
hensyn til i tabellen ettersom den kun presenterer innstegspris for hver løsning. Priser er 
regnet ut ved å benytte pris på enhet pluss eventuelt nødvendig ekstrautstyr i tillegg til 
en gjennomsnittspris på tilgjengelige abonnement om løsningen tilbyr flere 
abonnementsnivåer. Det tas forbehold om at priser vist her er estimert og beregnet ut 
fra informasjon funnet på leverandørenes nettsteder. Det er heller ikke gjort forsøk på å 
sammenlikne funksjonaliteten levert av hver leverandør med hverandre utover pris på 
løsningene og hvilke dekningsområder de har. Alle priser vises eks mva. 
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Løsning Kommunikasjonsmetode | Soner uten dekning | Pris pr år 

Findmy Satellitt Under fjellhyller eller 1980,- 
inntil vegg 

Telespor Telenett Områder uten mobilnett 1218,- 

Nofence Telenett Områder uten mobilnett 799,- 

Smartbjella Telenett Områder uten mobilnett 1128,- 

Beitesnap Telenett Ingen 1200,- 


Tabell 3.1: Oversikt over eksisterende løsninger 


Basert på dataen presentert over ser det ut som at det per i dag mangler løsninger på 
markedet som retter seg direkte mot manuell oppfølging av sau på beite. Selv om flere 
av løsningene forenkler arbeidet med oppsyn av dyrene er det fortsatt lovpålagt at 
dyrene skal ha oppsyn hver uke og dette bør dokumenteres om bonden ønsker refusjon 
for tapte dyr gjennom sesongen (Forskrift om velferd for småfe, 2005). Det kan derfor 
være rom og behov for løsninger som forenkler dette oppsynet. 


De fleste løsningene presentert i tabellen over baserer seg på teledata for registrering og 
formidling av data om dyrene på beite. Om man har beiteområder som ikke dekkes av 
telenettet kan dataen man mottar fra disse løsningene bli redusert og i noen tilfeller 
mangelfull. Til slutt er mange av løsningene presentert ovenfor kostbare ettersom de 
inkluderer fysiske IoT (Internet of Things) produkter i tillegg til abonnementsløsninger. 


For å sette prisene på løsningene i perspektiv kan man gjøre et generelt regnestykke på 
et gjennomsnittlig lam levert til slakt. I følge Animalia lå gjennomsnitts slaktevekt på et 
lam i 2021 på 18,8 kg (Røe, 2021). En bonde vil ifølge tabell for avregningspriser på 
småfe motta mellom kr 592.95,- og kr 1062,95,- for et lam med denne slaktevekten prisene er 
eksklusiv moms og grunntilskudd (Nortura, 2022). 


Teamet har gjennom sitt arbeid med gjennomgang av eksisterende løsninger identifisert 
at det kan være et potensielt marked for en løsning som forenkler det manuelle oppsynet 
med sauer på beite. En slik løsning bør være tilgjengelig i områder hvor det ikke er 
teledekning og la brukeren registrere data i offline modus. Ettersom et slikt system vil 
rette seg mot å effektivisere bondens manuelle oppfølging av sau vil løsningen dekke et 
marked som per i dag ikke direkte dekkes av noen av de andre leverandørene. Produktet 
har potensiale for å stille som en lavkostnadsløsning for oppsyn med sau i forhold til 
andre løsninger som benytter seg av IoT teknologi med enheter per dyr på beite. 


3.3 Tidligere arbeid 


Svein-Olaf Hvasshovd som er veileder for dette prosjektet har vært oppsynsperson for 
bønder med sauer på utmarksbeite i mange år og har inngående kjentskap til prosessene 
og systemene som omfatter denne praksisen. Grunnlaget for denne oppgaven og 
problemstillingene som tas opp bygger på hans erfaringer og tidligere prosjekter som er 
gjennomført på området. 


3.3.1 Kikkertmodus 
Etter lang fartstid med oppsynsvirksomhet på utmarksbeite har professor Hvasshovd 
erfart behovet for å kunne registrere sauer samtidig som man benytter seg av kikkert for 
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observasjon. Da dette var en utfordrende oppgave med penn og papir ble det undersøkt 
mer effektive og responsive måter å gjennomføre slik registrering av sau på (Hvasshovd, 
2021). Resultatene av undersøkelsene konkluderte med at en av de mest relevante 
måtene å løse dette på er ved at brukeren kan benytte skjermen på mobiltelefonen til å 
sveipe til høyre eller venstre for å registrere sau og at telefonen gir tilbakemelding til 
brukeren ved hjelp av lyd, slik at brukeren ikke behøver å se på telefonen under 
registrering. (Hvasshovd, 2021) Disse resultatene ble lagt til grunn når utviklingen av 
appen startet og det ble ikke gjort videre undersøkelser angående om det fantes mer 
effektive måter å gjennomføre slik registrering på, utover brukertester av den 
implementerte løsningen. 


3.3.2 Viktige data 


Gjennom sin erfaring med oppfølging av sau på beite har professor Hvasshovd 
identifisert en rekke data som ville være kritisk for bønder på oppsynstur å registrere. 
Denne dataen er samlet i den opprinnelige kravspesifikasjonen som kan finnes i vedlegg 
A og inkluderer: 


- —Observerte rovdyr 

- Døde dyr 

-  Skadde dyr 

-  Saueflokker og antall sauer 

- — Detaljer om hver sau som farge, ørelapp og slips 
- Hvem som gjennomførte turen 

- — Oppsynstur i kart 

- — Posisjoner for registreringer 

- Andre hendelser 


3.3.3 Kart 


Professor Hvasshovd har også identifisert en del behov som spesifikt går på bruk av kart 
og registrering av data i kart underveis i oppsynsrunden. Det viktigste appen må kunne 
håndtere når det kommer til kartbruk, er at brukeren må kunne velge et utsnitt av det 
området som brukeren ønsker å gå tur i. Dette utsnittet må kunne caches i telefonens 
minne slik at det er tilgjengelig om det ikke er mobildekning i områdene oppsynsturen 
blir gjennomført. 


Registreringen av flokker underveis i oppsynsturen, må også inneholde info om hvor 
brukeren stod da flokken ble sett. Det skal også tegnes en linje i kartet mellom 
registreringsposisjon og flokken. Årsaken til dette kravet er at det på et senere tidspunkt 
er interessant å vite hvor man stod da man så flokken og hvilken retning man så den i 
når man ser gjennom turen i ettertid. 


Når man er ute på tur kan det være veldig relevant for brukeren å kunne se tidligere 
turer og ha informasjon om hvor sauer har blitt observert tidligere. Dette for at 
oppsynsturer skal kunne varieres, men også for at det skal være mulig å gjenskape 
tidligere ruter og identifisere områder hvor sauer ofte beveger seg. 


I webapplikasjonen er det også en fordel om man når man går gjennom turer 
gjennomført i kartet kan se beitekvalitet i kartet. Det kan være relevant å kunne 
identifisere hvordan sauen beveger seg i relasjon til beitekvaliteten da det kan 
synliggjøre hvilke områder det er lurt å oppsøke ved inndrivingen av sauene. 
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4 Eget bidrag 


4.1 Metode og prosessverktøy 


4,1.1 Utviklingsmetodikk 

Før utviklingsperioden begynte, identifiserte teamet oppgaver som skulle gjennomføres 
og førte opp arbeidsoppgaver i store trekk. På bakgrunn av dette ble det utarbeidet et 

burndown chart for å holde kontroll på utviklingsprosessen for bedre å kunne estimere 

tidsbruken i prosjektet. Det fulle Gantt diagrammet finnes i vedlegg A. 


Progression plan 


Progression plan masters project 2021/2022 


Framework/Technology evaluation 
Researc h 


ng === === == =f====3| 
nt 
Paper prototyping 
Figma prototyping 
User testing 
Fundamental app setup 
Trip registration 


Mobile App main functionality 
Web App main functionality 
Stretch goals 

Report and Documentation 
Project diary 

Report 


Figur 4.1: Utsnitt av Gantt diagrammet for planlegging av prosjektet 


Gjennom prosjektperioden har teamet benyttet seg av en løs Kanban metodikk som 
utviklingsrammeverk. Kanban er en smidig utviklingsmetodikk hvor man har fokus på å 
ikke ha for mange oppgaver pågående om gangen og oppgaver blir tatt inn i 
arbeidsflyten etter hvert som teamet har kapasitet til å gjennomføre dem. Årsaken til at 
teamet har definert sin utviklingsmetode som løs Kanban, er at Kanban i utgangspunktet 
har en produkteier med ansvar for definering av oppgaver og prioritering av backloggen, 
som vil si ikke enda utførte oppgaver (Atlassian). Ettersom teamet kun bestod av to 
personer vekslet medlemmene på denne rollen. 


Ved bruk av Kanban bruker man et Kanbanbrett hvor oppgaver plasseres som kort på 
brettet og flyttes til rett kolonne basert på hvilken status oppgaven har. I løpet av 
prosjektperioden benyttet teamet seg av GitHub som versjoneringsverktøy for 
kodeoppgavene og dermed også Github's Kanban brett. De fleste oppgavene ble definert 
i begynnelsen av prosjektperioden og gruppert i større milepeler. 
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Oo & ThoMot / Beiteloggen > Projects Filter cards 


3 Todo 3 EE 2 In progress ap BD 20 Done =D 
O Tidligere turer ere O Feed hdd å WIP: Store trip upgraded 
430 opened by Certinax +29 opened by Certinax +56 opened by ThoMot Oo 
CP Uke g OP Uke 7 Oo 
O Changes approved 
O) Ferdigstille app EE O) Oppsett av API 
$31 opened by Certinax O 2 of 3 tasks O Implementer fullført tur 
GP Uke 8 P) +28 opened by Certinax EE ut een 
GP Uke 8 23 me 
O) Rendeflex overflow i Logg liste PE 1 linked pull request v 
+41 opened by Certinax 
[bus ] O Profilside - advanced 
O 3 of 4 tasks 
+27 opened by Certinax 
GP Uke7 23 


OQ Design fullført tur 


opened by Certinax 


å Completed trip overview 


+47 opened by Certinax 


tomated as To do Manage — Automated as In progress Manage — Automated as Done Manage 


Figur 4.2: Kanbanbrett for mobilapplikasjonsprosjektet underveis i utviklingsfasen 


Hvorfor Kanban: 


- Fleksibel arbeidsflyt hvor oppgavene prioriteres fortløpende passer fint for mindre 
team 

- Gir god oversikt over oppgavene som skal gjennomføres 

- —Begrensning av aktive oppgaver påfører større krav til å fullføre en oppgave før 
neste påbegynnes som sikrer fremgang i prosjektet 

- Gir en god oversikt over hva som er gjort og når det ble gjennomført 


Som nevnt i avsnittene over ble Github benyttet som versjoneringsverktøy sammen med 
Git som er grunnsteinen i kodeversjonering. Github bidro i stor grad til sømløs utvikling 
mellom de to team medlemmene hvor hvert medlem fortløpende kan utvikle en del av 
systemet for deretter å be den andre om kodeevaluering før endringene blir flettet inn i 
prosjektet. Teamet benyttet seg dermed flittig av Pull requests, Code reviews og merge 
commits inn i hovedprosjektet som levde i Github skyen som en «single source of truth». 


4,2 Kravspesifikasjoner 


Kravspesifikasjonene i denne seksjonen gir en oversikt over funksjonalitetskravene til 
mobilapplikasjonen og webapplikasjonen. Funksjonaliteten er gjennomarbeidet og 
definert ut fra kravspesifikasjonen som opprinnelig ble utarbeidet sammen med professor 
Hvasshovd i starten av prosjektfasen. Den er basert på hans erfaringer og tidligere 
undersøkelser på området. Mer om undersøkelser og arbeid gjennomført før 
prosjektfasen finnes under avsnittet «Tidligere arbeid». Den originale kravspesifikasjonen 
utarbeidet i samarbeid med professor Hvasshovd finnes i vedlegg B. 
Kravspesifikasjonene til mobilapplikasjonen og webapplikasjonen blir videre presentert i 
seksjonene under. 


Basert på kravspesifikasjonen har kravene til systemet blitt delt inn i funksjonelle og ikke 
funksjonelle krav, vist samlet i tabellen under. 
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Funksjonelle krav 


Ikke funksjonelle krav 


Opprette profil og lagre/endre/slette 
brukerdata 


Raskere å generere rapporter enn ved 
manuell opprettelse 


Opprette/Redigere/Se beitegrupper 


Enklere å finne beitedata/dyredata om din 
gård enn uten systemet 


Loggføre oppsynsturer med tilstrekkelig 
detaljnivå 


Raskt å laste inn data 


Se detaljer fra tidligere gjennomførte 
turer 


Følger gjeldende lover og regler angående 
personvern og GDPR 


Generere standardiserte rapporter for en 
beitesesong 


Data lagres sikkert og effektivt 


Se beitekvalitet i beiteområder i kart 


Tabell 4.1: Funksjonelle og Ikke funksjonelle krav for systemet 


4,2.1 Mobilapplikasjon 


Mobilapplikasjonens hovedformål er å tilby oversikt over brukerens profil, beitegruppene 
og aktivitet i gruppene brukeren er medlem av, og mulighet for registrering av 
oppsynsturer. Kravene under er strukturert etter appens hovedfunksjonaliteter. 


Feed 


Beitegrupper 


- Se nylig gjennomførte turer i de 
beitegruppene en er medlem av 

- Se detaljer om gjennomførte turer 
ved å aksessere en tur 

- Starte en ny oppsynstur 


- Se hvilke betasupper en er medlem 
av 

- Se nylig gjennomførte turer i 
beitegruppene 

- Se hvilke gårder som er med i 
beitegruppene 

- Se hvilke medlemmer som er med i 
beitegruppene 

- —Administrere beitegruppen om en 
er administrator 

- — Legge til medlemmer 

- Legge til gårder 


Tur 


Profil 


- Last ned kart over område 

- Start en oppsynstur 

- Registrer en observert saueflokk i 
manuellmodus eller i kikkermodus 
avhengig av avstand 

- Registrer tapte dyr eller 
rovdyrsobservasjoner 

- — Registrer annen info om turen 

- Fullfør og se oversikt over turen 


- — Last opp dine turer til skyen 

- Endre profil 

- — Administrer invitasjoner til 
beitegrupper 

- Slett profil 

- Logg ut 


Tabell 4.2: Oversikt over krav til mobilapplikasjonens funksjonalitet 
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Basert på kravene presentert ovenfor ble det utarbeidet et «Use case», for å bedre 
illustrere de funksjonene og aktivitetene en bruker skal ha mulighet til å gjennomføre i 
mobilapplikasjonen. Brukeren er her definert som en person innenfor målgruppen til 
systemet som er spesifisert i seksjonen «Målgrupper». 


Opprett profil 
pen 
<<extend>> tt 
Com) AsassnsE Gå til profil 
enga, 


Siinclude=> f Registrere 
Bruker azextend?? detaljer 
pene 
Gå til Feed å 
h-. .S8xtend»» 
pt on Se detaljer om 
Ed tur 
Brukeren må f-” «add 
være 
innlogget fy elg gjennomført 
NN g tur 


Gå til 


Beitegrupper Å. ex, ae 
hal Opprett "af Se detaljer om 
beitegruppe gruppe 


Figur 4.3: Use case for mobilapplikasjonen som viser potensielle bruksmønstre 


Gjennom kravutformingen ble det også nedsatt noen tekniske krav for 
mobilapplikasjonen. De tekniske kravene som ble utarbeidet er vist i tabellen under. Den 
originale utarbeidede listen finnes i vedlegg B. Disse tekniske kravene er lagt til grunn for 
valg av hvilke teknologier prosjektet er laget med. 


Tekniske krav til mobilapplikasjonen 


Appen skal være tilgjengelig på iOS og Android for å nå de aller fleste brukerne 
Må støtte Android versjon 10 «Queen Cake» eller høyere siden det er siste versjon 
med sikkerhets støtte (endoflife) 
Må støtte siste versjon av iOS versjon 12.4.x eller høyere, dette inkluderer iPhone 65 
og senere (Apple) 
Må ha støtte for GPS 
Må kunne behandle og vise kartdata offline (Ønsket kartdata fra kartverket) 
Må kunne håndtere Text-to-speech/talemelding 
Må kunne håndtere loggføring uten internettilgang 
Må kunne laste opp loggdata i skyen via wifi 
Tabell 4.3: Tekniske krav for mobilapplikasjonen 
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4,2.2 Webapplikasjon 

Webapplikasjonens hovedformål er å gi brukeren en oversikt over data samlet gjennom 
sesongen, oversikt over brukerens profil og grupper, i tillegg til generering av rapporter 
basert på sesongens data for innsendelse til Miljødirektoratet. 


Dashbord 


- Se hvilke grupper du er medlem i 

- Se nylig gjennomførte turer i beitegruppene 

- Se hvilke gårder som er med i beitegruppene 

- Se hvilke medlemmer som er med i beitegruppene 

- Se nylig gjennomførte turer i de beitegruppene du er medlem av 
- Se detaljer om gjennomførte turer ved å aksessere en tur 

- Se beitekvaliteten i beiteområdene i kart 


Rapport 


- Velge en beitesesong å generere for 
- Velge beitegruppe å generere for 

- —Generere rapport basert på valg 

- — Printing / lagring av rapport 


Profil 


- — Endre profil 
- Slette profil 
- Logge ut 
Tabell 4.4: Oversikt over krav til webapplikasjonens hovedfunksjonalitet 


Webapplikasjonens use case presentert nedenfor presenterer aktiviteter og funksjoner en 
bruker skal kunne gjennomføre i Webapplikasjonen. Funksjonaliteten er basert på 
kravene presentert i tabellen over. 


Opprett profil 


4 endre profil 
aent e==r 
AEE Gå til profil 
*=Nrlengs, 


a <<include>> <<extend>> 
Bruker Gå til Rapporter |-------===-=- Velg periode |æ-------------- Produser rapport 
Brukeren må f-- 
være 
innlogget fs <æextend>> (Velg gjennomført) <<indlude>> f Se detaljer om 
Temes tur ik 
Å <<include>> 
Gå til Dashbord |------=-----4 Velg en 
beitegruppe 
6 ISMcluge, 
T==2m.p/ Se detaljer om 
gruppe 


Figur 4.4: Use case for webapplikasjonen som viser potensielle bruksmønstre 


o 
a 
3 

å 
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4.3 Konseptutforming 


På bakgrunn av den utformede kravspesifikasjonen og use case diagrammene diskutert i 
seksjonen over, ble det utarbeidet et første utkast for hva systemet skulle inneholde av 
funksjonalitet. Måten teamet arbeidet på var ved å gå steg for steg gjennom systemet og 
kartlegge en flyt som føltes naturlig. Hver Post it representerer et steg hvor brukeren kan 
utføre en handling eller observere data, forskjellige aksjonsområdene i flyten ble gitt 
samme farge. Hele flyten for både webapplikasjonen og mobilapplikasjonen kan 
observeres i vedlegg C og D. Figur 4.5 viser et utsnitt av applikasjonsflyten for 
registrering av en flokk. 


A flock of sheep registration flow 


Figur 4.5: Første utkast for applikasjonsflyt for registrering av en flokk under en 
oppsynstur. 


Etter at funksjonsflyten i applikasjonen var kartlagt, ble det utviklet en konseptuell 
modell for systemet. Den konseptuelle modellen ble utarbeidet med bakgrunn i teorien 
om at ved å utarbeide slike modeller før design av brukergrensesnittet, kan man bidra til 
å gjøre konseptene applikasjonen presenterer klarere og mer logiske for brukeren 
(Johnson, 2008). Den relasjonelle modellen som viser relasjonene mellom de forskjellige 
konseptene i applikasjonen vises i figur 4.6. Hvert konsept har egne attributter og 
knyttes til andre konsepter i modellen gjennom relasjoner. Hver linje er nummerert for å 
illustrere antallet andre konsepter som kan være relatert til en enkelt instans av hvert 
enkelt konsept. Flere detaljer om den konseptuelle modellen finnes i vedlegg E. 
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User 
Email 
First name 
Last name 
Picture 
Admin status 


Group affiliations 


(0,n) 
Performed trips 
(0,n) (0,n) 
reates 
lember oi Sn 
) (1,n) i) 
Grazing Group Flock 
Trip 
Name I Sheep 
Flocks 
Members HO, n)=<Belongs to 9) (0, nj—Belongs to (1) Lambs 
—] Distance 
Trips Note 
Positions 
Farms Positions 
Events | 
(0, n) (0,n) (0,n) 
(0,n) 
Belongs to 
Belongs to 
(1) b Å 
(1) 
Farm Lamb | Sheep 
Name Event Color Color 
Color Title Tag color Tie color 
Description Condition Tag color 
Category Note Condition 
Position Note 


Figur 4.6: Relasjonell modell for systemet 


For å få bedre innsikt i målgruppen og illustrere hvilke problemer brukerne står overfor i 
dag utviklet teamet to «personas». Personas brukes for å representere typiske brukere 
av løsningen for å bedre forså brukernes ønsker, behov og forventninger (Rikke Friis 
Dam, 2022). Bakgrunnen for personaene utviklet i prosjektet er intervjuer gjennomført 
med professor Hvasshovd og basert på hans erfaringer på området. Personaene som ble 
utformet har forskjellige karakteristikker og representerer to forskjellige brukere med 
forskjellige behov og ønsker til systemet. Gjennom disse personaene ble det enklere å 
visualisere en sluttbruker og gjøre prosessen mer brukersentrert. Figur 4.7 viser en av 
personaene som ble utarbeidet. Begge personaene finnes i vedlegg F og G. 
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Mal fra: TDT4180 HCI — 2021 


Bonde 5060 


Odd Larsen 


Hardt arbeid er realt arbeid 


Ek 


Bio 

« Odd er en hardtarbeidende og 
selvstendig bonde som er opptatt av å 
gjennomføre oppgavene sine på en 
ordentlig måte i henhold til loven men er 
også opptatt av at ting skal være 
praktisk. 

Mål 

Følge lover og regler om dyrehold på 

utmarksbeite 

* Gjennomføre jobben sin på en effektiv 
måte 

« Drifte på en skikkelig, men også 
profitabel måte 


Frustrasjoner 

« Må forholde seg til andre som ikke 
gjennomfører oppsyn skikkelig 

« For mye arbeid å produsere rapporter for 
dokumentasjon til myndighetene 

« Vanskelig å finne igjen sau om høsten 


ØNTNI 

Personlighet 
Ekstrovert [j Introvert 
Sansing In] Intuisjon 
Tenking | Føling 
Dømming [] Oppfattelse 
Passiv å Aktiv 
Lojal In) Flytende 
Oppførsel 
« Gjør gjerne jobben selv for at den skal 

gjøres skikkelig 


e Arbeider effektivt 

« Behandler sauene sine godt og blir 
frustrert av tap ettersom det koster ham 
mye penger 


Oppgavespesifikk seksjon 

e Vil ha et felles system for strukturering 
av informasjon 

e Vil ha tilgang til informasjon om sine 
sauer så raskt som mulig 

«Vil ha en mer effektiv måte å generere 
rapporter til myndighetene på 


Bonde Motivasjoner «Vil ha et system som er enkelt å bruke 
sans ra en — 

Oppdal —— 

ge er 


Hardtarbeidende Selvstendig 


Figur 4.7: Odd Larsen er en av de to personaene i prosjektet 


4,4 Design og utforming 


Det fantes ingen retningslinjer for hvordan det nye systemet skulle se ut, noe som gå 
teamet frie tøyler til å utarbeide designet. Valgene er likevel basert på litteratur og 
kjente konvensjoner, for å sikre så god brukeropplevelse som mulig og etterlevelse av 
krav og retningslinjer om universell utforming er blitt fulgt. Designet og utformingen av 
applikasjonen har blitt utarbeidet iterativt gjennom bruk av brukertester og kontinuerlig 
evaluering av brukeropplevelsen på forskjellige stadier i utviklingsprosessen. 


4.4.1 Brukeropplevelse 
Brukeropplevelse handler om hvordan brukerne opplever en applikasjon, hvor lett den er 
å bruke og hvor enkelt det er å forstå eksisterende funksjonalitet. 


Ved utarbeidelse av appens utforming og struktur har teamet hatt stort fokus på 
informasjonsarkitektur for å opparbeide en logisk struktur som er intuitiv for brukeren. 
Hvilken informasjon som er blitt vurdert som viktigst for brukeren har teamet kommet 
frem til ved å basere seg på professor Hvasshovds erfaring på området. Kartleggingen 
bestod i å først gjennomgå den utarbeidede kravspesifikasjonen og deretter å gruppere 
de viktigste funksjonene og informasjonen, slik at et tydeligere behovshierarki kom fram. 
Det har vært et viktig element at brukerne ikke føler seg overveldet av for mange valg, 
noe som også har påvirket appens grunnleggende utforming. 


På navigasjonsbaren i mobilapplikasjonen kan man identifisere tre av de fire 
hovedområdene i appen som alle lar brukeren navigere seg dypere i hierarkiet. Siden 
brukeren er på, vil til enhver tid være uthevet i navigasjonsbaren. Denne markeringen i 
tillegg til tilbakepilene som kommer til syne på topplinjen når man har navigert seg 
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nedover i app-hierarkiet for å nå en spesifikk funksjon, bidrar til at brukeren ikke blir 
forvirret angående sin posisjon. 


Hjem 


Figur 4.8: Navigasjonsmenyen i mobilapplikasjonen og pil for tilbake navigering i 
toppmenyen i mobilapplikasjonen 


Gjennom utarbeidelsen av designet har det vært fokus på å overholde Don Normans 
designprinsipper som har som mål å forbedre brukeropplevelser og gjøre bruken av et 
produkt mer intuitivt (Batterbee, 2020). I tillegg har både Jacob Nielsens prinsipper for 
interaksjonsdesign og Gestalt prinsippene blitt lagt til grunn for applikasjonens utforming 
og design (Nielsen, 2020) (Sandnes, 2018). 


Et eksempel på slik gjennomarbeidelse er at det har vært et gjennomgående fokus på at 
tekst på knapper og andre elementer skal være forståelig og gi brukeren en klar 
indikasjon om hvilken funksjonalitet som ligger bak. Dette er viktig for å forhindre at 
brukeren blir forvirret når det gjelder hvilken funksjonalitet som er tilgjengelig eller at 
brukeren utfører handlinger de ikke ønsket å utføre. og er viktige elementer i Don 
Normans syv fundamentale design prinsipper (Batterbee, 2020). Figur 4.9 under viser et 
eksempel på dette hvor både tekst og ikoner er benyttet for å indikere til brukeren 
hvilken funksjon som ligger bak knappene. 


ss Oppdalsgruppa 


ko Innstillinger > VE 28.5.2022 19:01 
JE 4 Hans Karlsen 
seg Hedmarksgjengen 
t Last opp ny tur > KE 23.5.2022 19:04 


- Mons Arnesen 


ss Oppdalsgruppa 
EF Mine invitasjoner > VE 21.5.2022 17:50 
HS Anna Fredriksen 


Figur 4.9: Knapper for valg på profilsiden i Figur 4.10: Knapper for valg av tur på 
mobilapplikasjonen Hjemskjermen 


Gjennom mobilappen og webapplikasjonen har det vært fokus på å la 
interaksjonselementer se like ut slik at det for en bruker er intuitivt at elelmentet kan 
interageres med. I figur 4.10 vises interaksjonselementene for å åpne en tur på 
hjemskjermen. Man kan observere at elementene ser like ut som knappene på 
profilsiden, hvor hvert element har et ledende element pluss beskrivende tekst for turen 
eller siden man blir navigert til. Dette følger Jacob Nielses prinsipper om «Concistency» 
for å møte brukernes forventninger (Nielsen, 2020) 


Et annet designmønster i mobilapplikasjonen, som faller inn under «Concistency» 
prinsippet er bruk av den runde aksjonsknappen på flere sider. Denne knappen finnes 
alltid på samme styed og indikerer at det kan registreres eller legges til noe nytt på 
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denne siden. Gjennom appen fungerer denne knappen for å opprette en ny tur, starte en 
ny tur, for å legge til en ny beitegurppe og for å registrere en ny saueflokk. 


Figur 4.11: Oversikt over de forskjellige aksjonsknappene i 
mobilapplikasjonen 


For å tilby brukeren en gjennomgående opplevelse i både mobilapplikasjon og 
webapplikasjon ble det lagt vekt på å gjennbruke det samme fargeuttrykket og 
elementutformingen i begge løsnigner. I begge applikasjonene ble det satt opp 
temakomponenter for fargevalg og utforming, slik at om noe skulle måtte endres på et 
senere tidspunkt ville det være enkelt å gjøre tilpassninger i begge applikasjonene. 


4.4,2 Bilder og ikoner 

På generell basis er ikoner og bilder kun brukt som tilleggsinformasjon, i tillegg til tekst i 
begge applikasjoner for å imøtekomme krav til tilgjengelighet. Fokuset på tilgjengelighet 
diskuteres ytterligere i avsnittet «Tilgjengelighet». Likevel er ikoner en mye brukt og 
anerkjent konvensjon i mobilapplikasjoner og de er også blitt benyttet enkelte steder i 
applikasjonen for illustrasjon av funksjonalitet eller som typeindikator. 


Et eksempel på dette er ikonene på aksjonsknappene som illustrert i figur 4.11. Her 
indikerer ikonene forskjellig funksjonalitet ut fra hvor i appen brukeren befinner seg. Et 
annet eksempel er tannhjulet eller menyikonet som finnes i toppbaren ved gjennomføring 
av en tur som åpner forskjellige menyer med valg for brukeren. 


Ikoner benyttes også i kartløsningene i både mobil og webapplikasjonen for å illustrere 
registrerte hendelser, flokker og hvor brukeren har beveget seg. Ikonene for registrerte 
hendelser og brukerens posisjon er hentet fra ikonbiblioteker som tilbyr gratis ikoner for 
bruk i personlige og kommersielle løsninger. Ikonet for registrering av saueflokker er 
designet på egenhånd i Figma. 


Figur 4.12: Ikoner som brukes i kartløsningen 


4.5 Brukertesting av utforming og design 


Som introdusert i seksjonen «Metode» tidligere i denne rapporten har det blitt 
gjennomført flere brukertester gjennom prosjektet for å sikre at det endelige produktet 
møter de ønskene og forventningene brukerne har. 
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Før utviklingsprosessen ble påbegynt ble det utviklet en papirprototype som et «proof of 
concept» som ble testet på brukerne for å identifisere om strukturen og hoved 
funksjonaliteten i mobilapplikasjonen var intuitiv. På bakgrunn av resultatene fra denne 
testen ble det utarbeidet en mer detaljert prototype i Figma. Figma lar utviklere og 
designere implementere applikasjons-lik oppførsel og funksjonalitet i prototypen, slik at 
brukerne får en bedre opplevelse av hvordan flyten, følelsen, navigasjonen og uttrykket i 
en applikasjon vil være i det endelige produktet (Figma). 


I denne seksjonen vil testene av papirprototypen og Figma prototypen bli presentert i 
tillegg til resultatene som la grunnlag for utviklingen av det endelige produktet. Figuren 
under viser testrekkefølgen gjennom prosjektet og hvilke tester som vil dekkes i denne 
seksjonen. Den siste testen som vises i modellen, vil beskrives i avsnittet «Resultater» i 
denne rapporten. 


Proof of concept | Test Figma prototype Applikasjon p 


Figur 4.13: Testrekkefølge i prosjektet og relevante tester for seksjonen 


4,5.1 Gjennomføring av brukertester 

Ved gjennomføringen av alle brukertestene ble det utarbeidet en test plan hvor testen 
ble delt opp i tre deler. Den første testseksjonen bestod av informasjon til testeren 
angående gjennomføring av testen og formålet med applikasjonen. En detaljert 
beskrivelse av informasjonen som ble gitt kan finnes i vedlegg H. I den andre 
testseksjonen fikk brukeren utføre flere oppgaver gitt av testadministrator, uten 
veiledning og til det beste av deres evne. Brukeren ble bedt om å beskrive sine 
tankeprosesser underveis og hvilke problemer eller andre tanker som oppstod i løpet av 
utførelsen av hver oppgave. En person i teamet hadde ansvar for oppfølging av brukeren 
og gjennomføring av testen, mens det andre team medlemmet hadde ansvar for å notere 
hendelser og relevante tanker brukerne hadde. En liste over alle oppgavene gitt under de 
forskjellige testene finnes i vedlegg I, J og K. Den siste delen av testen bestod av en 
friere seksjon hvor brukeren ble stilt planlagte spørsmål som handlet om spesifikke deler 
av systemet og brukeren kunne komme med andre tilbakemeldinger. Disse spørsmålene 
kan også sees i vedlegg I, J og K. 


4,5.2 Papir prototype, Mobilapplikasjon 

Testen ble gjennomført ved at et av teammedlemmene opptrådde som en «Wizard of 
Oz», som hadde ansvar for å holde styr på applikasjonens status ettersom brukeren 
ønsket å navigere seg gjennom prototypen. Dette innebar å bytte sider, legge frem 
modaler og vise tilbakemeldinger på hva brukeren ønsket å gjennomføre. Hovedformålet 
med å gjennomføre denne typen tidligtest av løsningen, var å få tilbakemelding fra 
brukere på strukturen og flyten i applikasjonen uten at fokuset blir flyttet over på det 
visuelle som farger, ikoner og liknende (Babich, 2017). Figurene under viser et utdrag av 
papirprototypen som ble utviklet, flere bilder av prototypen finnes i vedlegg L. 
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Figur 4.14: Hjem skjerm Figur 4.15: Oversikt over Figur 4.16: Start ny tur 
papirprototype beitegrupper skjerm 


Papirprototypen av systemet ble testet på tre brukere, en bruker med domenespesifikk 
kunnskap og to generelle testere. Et sammendrag av funnene fra testen av 
papirprototypen er presentert i tabellen under. PP i tabellen refererer til «Papirprototype 
problem» og PL refererer til «Papirprototype løsning» 
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Sammendrag av papirprototypens testresultater, Mobilapplikasjon 


Bruker Problem Foreslått Løsning 
Domeneekspert PP1: Gårder gir ikke mening PL1: Fjerne gårder ettersom 
som et eget valg ettersom det | informasjonen om dem allerede 
ikke finnes unik info om dem finnes i beitegruppeentiteten. 


der. 
Domeneekspert PP2: Kikkertmodus er altfor PL2: Korte ned kikkertflyten og la 
detaljert. Man vil aldri ha brukeren gå ut av registreringen 


mulighet til å «gå tilbake» og | når de eventuelt er ferdige å 
registrere flere detaljer om en | registrere antall sau om de ikke 
Sau kan se farge 

Generell bruker 1 | PP3: Forstod ikke hva Gårder | PL3: Se foreslått løsning PL1 

i navbaren hadde som formål 


Generell bruker 2 | PP4: Kunne kanskje vært PL4: Legge til hvilken gård hver 
relevant å kunne se hvilken oppsynsperson tilhører når man 
gård hver oppsynsperson viser turer 


hører til inne i en beitegruppe 
Generell bruker 2 | PP5: Litt rotete under kikkert | PL5: Se foreslått løsning PL2 
registreringen 


Generell bruker 2 | PP6: Litt generell forvirring PL6: Etter kort intervju med 
angående hva som er knapper | testsubjektet avdekkes det at 
og ikke dette er mer på grunn av den flate 
papir prototypen enn designvalg 
Generell bruker 2 | PP7: Litt forvirrende at PL7: Navngivningen på forsiden 
hendelser på forsiden ikke er endres til «Feed» ettersom dette 
det samme som hendelser passer bedre med dataen som 
man registrerer på tur. faktisk vises der 


Tabell 4.5: Sammendrag av papirprototypens resultater (Thora Mothes, 2021) 


På bakgrunn av det som ble funnet i testen av papirprototypen ble det fastslått å fjerne 
«Gårder» fra navigasjonsmenyen, da flere av testsubjektene ikke så nytten av entiteten. 
Gårder ble i stedet kun en del av en beitegruppe. En bruker nevnte at det kunne være 
nyttig å se hvilken oppsynsperson som hørte til hvilken gård, men etter diskusjon med 
domeneeksperten ble det fastslått at dette ikke var et prioriteringsområde. I tillegg ble 
det avdekket at designet og utformingen av kikkertregistreringen var altfor detaljert. På 
bakgrunn av denne tilbakemeldingen ble flyten i kikkertmodus gjennomarbeidet på nytt 
for å bedre imøtekomme brukernes ønsker og forventninger til funksjonaliteten. 


4.5.3 Figma prototype, Mobilapplikasjon 

Basert på tilbakemeldingene mottatt ved testingen av papirprototypen, utviklet teamet 
en ny prototype i Figma. Gjennom bruk av Figma var det enklere å vise brukerne 
hvordan flyten vil se ut i en reell applikasjon, det ble også lagt vekt på noen av de finere 
detaljene i applikasjonen i tillegg til den helhetlige brukeropplevelsen. Figma prototypen 
ble designet i henhold til WCAG standarder (W3C Web Accessibility Initiative WAI, 2018) 
og det ble vektlagt å følge designprinsipper som Jacob Nielsen og Gestalt (Nielsen, 2020) 
(Sandnes, 2018). Bildene under viser et utdrag av skjermbilder fra Figma prototypen. For 
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en full oversikt over Figma prototypen se vedlegg M og for en full oversikt over 
navigasjonsstrukturen som ble opparbeidet for testing se vedlegg N. 


Antall dyr 


Ø balføret Beitegruppe Dalføret 


Kart 12.09.21 0 Grå sau 0 Grå lam 
Rød Gård - Per Stålesen 


Aktivitetslogg 


Beiteområde Vestre område 
0 Brun sau 0 Brunt lam 


Tregrensa 
9 Last ned kart over beiteområde — Obs. kart er ikke 
09.08.21 nedlastet 


Gul Gård - Jan Johansen 


0 Sort sau 0 Sort lam 


Dalføret 


05.08.21 
Blå Gård - Truls Nilsen 


Dalføret 
09.07.21 
Rød Gård - Svein Petter Olsen 


Tregrensa 
06.07.21 


Brun Gård - Rita Rønning + 


W R 


Beitegrupper Profile 


Figur 4.17: Hjem skjerm Figur 4.18: Start tur skjerm Figur 4.19: Kikkert modus 
for registrering av sau 


Brukertestingen av Figma applikasjonen ble gjennomført i to runder. I begge runder ble 
systemet testet på domeneeksperten, og tre generelle brukere. Tilbakemeldinger fra 
runde nummer en ble vurdert og implementert i løsningen før testrunde nummer to ble 
gjennomført. Tabellene under presenterer problemene og de potensielle løsningene, 
identifisert gjennom de to brukertestene av Figma prototypen. 
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Sammendrag av Figma prototype 1s testresultater, Mobilapplikasjon 


Bruker Problem Foreslått Løsning 
Domenebruker F1P1: Litt forvirrende at man | F1L1: Dette er på grunn av 
måtte klikke på den store limitasjoner i Figma. Det vil ikke 
knappen for å få den til å fungere slik i den endelige 
legge til eller fjerne sau i løsningen. 


kikkertmodus, forventet å 
kunne sveipe. 
Domenebruker F1P2: En burde ha mulighet F1L2: Dette er allerede en 

til å forlate kikkertmodus for mulighet gjennom knappen i øvre 


registrering etter å kun ha høyre hjørne. Det vurderes ikke at 
registrert antall sauer. det trengs flere måter å bryte 
flyten på. 

Generell bruker 1 | F1P3: Ser ikke behovet for F1L3: Endre input felt til knapper 
måtte skrive inn tall for å for å legge til eller fjerne antall 
legge til sauer. Tungvint. sauer. 

Generell bruker 1 | F1P4: Den store knappen i F1L4: Se løsning F1L1. 


kikkertmodus ser ut som noe 
man kan sveipe og ikke noe 
man kan klikke. 

Generell bruker 2 | F1P5: Litt vanskelig å forstå F1L5: Ingen behov for løsning 
at man kan bytte mellom 
kikkertmodus og manuell 
modus, men forstod etter litt 
tid. 

Generell bruker 3 | F1P6: Kanskje ikke behov for | F1L6: Se løsning F1L3. 
inputfelter for å skrive inn 
hvor mange sauer man ser i 
manuell modus. 

Figur 4.20: Sammendrag av Figma prototype 1s resultater (Thora Mothes, 2021) 


Et av hovedelementene brukerne registrerte under gjennomførelsen av testen var at den 
store knappen i kikkertmodus for registrering av sauer, så ut som en knapp som kunne 
sveipes eller dras over skjermen, mens man i testen var nødt til å klikke på sidene. 
Årsaken til dette lå ikke i design, men i limitasjoner i Figma, hvor det ikke er mulig å 
gjøre et element sveipbart mer enn en vei om gangen. Dette ble likevel evaluert og tatt 
med videre til produksjon som en indikasjon på at den utformede knappen var intuitiv for 
sveiping. 


Et annet element som var svært relevant for videre design, var at flere brukere kom med 
tilbakemeldinger om at input-feltene i manuell modus ikke var intuitive for registrering 
av sauer. En av brukerne bemerket at knapper hadde vært bedre enn input felt. Dette 
ble implementert i Figma prototypen før den neste testen ble gjennomført. 
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Sammendrag 


av Figma prototype 2s testresultater, Mobilapplikasjon 


ikke er noen mate å avbryte 
registrering av en flokk i 
kartet på 


Bruker Problem Foreslått løsning 
Domenebruker F2P1: Knappene for å legge F2L1: Øke størrelsen på pluss og 
til sau kan være større. minus knappene under manuell 
registrering. 
Domenebruker F2P2: Det virker som at det F2L2: Legg til funksjonalitet for å 


kansellere registrering av en flokk 
ved å splitte opp 
registreringsknappen i to. 


Generell bruker 1 


F2P3: Kartet kunne vært 
større på start tur skjermen 


F2L3: Tatt med videre som et 
designvalg til 
applikasjonsutviklingen 


Generell bruker 1 


Generell bruker 2 


Generell bruker 2 


F2P4: Kunne vært fint å 
kunne legge inn en 
kommentar på en enkelt sau 
F2P5: Det finnes ingen måte 
å markere sau som er skadet 
på. 

F2P6: Ikke mulig å se hvilken 
beitegruppe man er i når man 
går en tur 


F2L4: Legg til kommentarfelt på 
hver sau i tilfelle det finnes 
spesifikke ting å notere. 

F2L5: Legge til knapp for å 
indikere skadet sau 


F2L6: Legg beitegruppenavnet til i 
menyen mens man gåren tur 


Generell bruker 3 


F2P7: Kan ikke avbryte 
registrering i kart når man 
har klikket på flokkikonet 


F2L7: Se løsning F2L2 


Tabell 4.6: Sammendrag av Figma prototype 2s resultater (Thora Mothes, 2021) 


Gjennom test nummer to av Figma prototypen, ble det avdekket flere nye problemer. 
Teamet har mistanke om at grunnen til at det ble avdekket flere problemer i runde to var 
at brukerne ble mer og mer kjent med løsningen de testet. Den mest signifikante av 
manglene identifisert, var at det ikke fantes noen måte å avbryte registreringen av 
flokker i kartet når man gikk inn i markeringsmodus. Dette ble tatt med som et viktig 
element til utviklingsfasen i tillegg til de andre elementene som stort sett bestod av 
utbedringer i relasjon til brukeropplevelsen og ekstra registreringsdetaljer. 


4.5.4 Figma prototype, Webapplikasjon 
Det ble også utviklet en Figma prototype for Webapplikasjonen. I designet ble det lagt 
vekt på å fremheve den viktigste og mest relevante informasjonen og at brukeren skulle 
ha tilgang til ønsket informasjon med færrest mulig klikk. Under er to bilder av det 
endelige Figma designet. Hele Figma prototypen kan sees i vedlegg O og 
navigasjonsstrukturen finnes i vedlegg Q. 
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Dashbord 


å 
080 Sesong 2022 GrazingGroup 1 v 


Gårder 


Ted H 
CM Døde sauer Turer gått Rovdyr sett Skadde sauer 


7 2 Røed Gård 


d 2 2 2 


Dashbord 4 Frøysa Gård 


En Årets turer Å Rælingen Gård 


Rapporter Dato Oppsynsperson Sauer sett Hendelser 
Å Rygge Gård 


04.01.2022 Ted Hansen 14 va 


Medlemmer 
20.01.2022 Kim Tronsen 18 vA 
Ted Hansen 


02.02.2022 åge Normann : vw 

Kim Tronsen 
05.02.2022 Tore Fransen 

Åge Normann 


24.02.2022 Kim Tronsen 


Tore Fransen 
17.03.2022 Ken Yee 


01.04.2022 Åge Normann 


Figur 4.21: Dashbord i webapplikasjonen. 


GrazingGroup 1 
Ted Hansen - 04.01.2022 


este 1 Artall bm Hieysbad er : Flokker 
23.34 km åt 235m 43 Flokk 1 
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ar 


Fløkk 3 


7 oa å lar 


Déicken 


Flokk 4 


roe 15 


Flokk 5 


F vakt "å bar 


Storsiåpå 


Hendelser 
Hendelse tittel 1 


Dyskt dyr - 8 1000 


Hendeise tittel 2 
Moray «41 1203 


Handelse tittel 3 
Notat - bd 10333 


knutshe 
== 
XP 


Flokk 1 


Arrsdl 98 


4 


Kinbsenshet 


10:03 


+ Gert på 
Karman 
lan peaen teke et amet, onemmetre af påvåe3 
ee 
Selen neger al og Lt pek 9å orker verken, 
qam marnud se lader karen buborta rest ul 
Vips par av core od verse Et 


Figur 4.22: Oversikt over en gjennomført tur. 
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Tabellen viser oversikten over problemer og løsninger som ble identifisert gjennom 
brukertesten. Hvilke spørsmål som ble stilt og mer utfyllende svar finnes i vedlegg P. 


Sammendrag av Figma prototypens testresultater, 
Webapplikasjon 


Bruker Problem Foreslått løsning 
Domenebruker F3P1: Finnes ingen linje F3L1: Legge til linje i kartet inne 
mellom registereringsposisjon | på en tur. 
og registrert flokk i kartet 


Domenebruker F3P2: Ønsket å se F3L2: Implementere mulighet for 
beitekvalitet i kartet. å se beitekvalitet i samsvar med 
en tur. 


Generell bruker 1 | F3P3: Litt uoversiktlig med F3L3: Bruke dropdown for å velge 
en knapp for å se flere turer. relevant sesong. 


Generell bruker 1 | F3P4: Ingen mulighet for å F3L4: Legge til tegnforklaring for 
se hva de forskjellige ikonene | kartikoner. 
i kartet betyr. 


Generell bruker 2 | F3P5: Vil kunne klikke på F3L5: Gjøre ikoner i kartet 
kartet for å se info om flokker | klikkbare for å gi mer informasjon 
og hendelser. om dem. 

Generell bruker 2 | F3P6: Litt vanskelig å vite F3L6: Se F3L4. 
hva alle ikonene i kartet 
betyr. 

Generell bruker 3 | F3P7: Litt vanskelig å se F3L7: Gjøre designet på ikke- 
forskjell på hva som er knapper flatere så de ikke ser 
knapper og ikke. klikkbare ut. 


Tabell 4.7: Oversikt over resultatene av brukertest av Figma prototype for 
webapplikasjon 


Domenebrukeren hadde noen punkter (se F3P1 og F3P2), angående data som ikke var 
tilgjengelig i Figma prototypen. Dette ble notert ned og tatt med videre til 
utviklingsstadiet. De andre testerne kom med tilbakemeldinger om data i kartet som var 
uklar og at noen av elementene i designet var uklare når det kom til om de var klikkbare 
eller ikke. Dette designet ble revidert i utviklingsfasen og ekstra informasjon rundt kartet 
ble lagt til. 


4.5.5 Konklusjon 

Etter gjennomføringen av brukertestene og evaluering av tilbakemeldingene ble den 
endelige flyten av applikasjonene og systemet fastsatt. Figurene under viser forenklede 
illustrasjoner av flyten i mobilapplikasjonen og webapplikasjonen etter revideringer i 
henhold til de tilbakemeldingene teamet fikk gjennom de avholdte testene. På bakgrunn 
av den gjennomførte iterative designprosessen ved hjelp av brukertester, ble 
utviklingsperioden startet. 
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Figur 4.23: Endelig applikasjonsflyt i mobilapplikasjonen 
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Tabell 4.8: Endelig applikasjonsflyt i webapplikasjonen 
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4.6 Produkt 


Etter at det var gjennomført flere brukertester av løsningen hvor både flyten og designet 
av systemet hadde blitt revidert ble utviklingsfasen påbegynt. Utviklingsfasen var den 
lengste fasen av prosjektet og varte frem til få uker før prosjektavslutning. 
Sluttproduktet resulterte i et nesten lanseringsklart system. I denne seksjonen 
presenteres det endelige systemet, bestående av en mobilapplikasjon og en 
webapplikasjon. 


4,6.1 Mobilapplikasjon 
Mobilapplikasjonen tilbyr brukeren funksjonalitet for å: 


- Opprette, administrere og slette sin brukerprofil. 

- Opprette, administrere og slette beitegrupper. 

- — Akseptere invitasjoner til beitegrupper. 

- Gjennomføre oppsynsturer med registrering av observasjoner. 

-  Opplasting til skyen etter gjennomførte turer. 

- — Mulighet til å evaluere tidligere gjennomførte turer i beitegruppene I seksjonen. 


I dette avsnittet vil disse funksjonalitetene bli presentert i større detalj. 
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4.6.1.1 Opprett bruker 


Logg inn via den magiske linken med mailen din 
under 
Email 


Email 


Passord [OJ 


Opprett konto Glemt passord 


Figur 4.24: Loginside for Figur 4.25: Profilopprettelse i 
mobilapplikasjonen mobilapplikasjonen 


Når en bruker aksesserer appen for første gang blir de møtt med en innloggingsskjerm. 
Ingen av sidene i applikasjonen er tilgjengelige uten innlogging da all funksjonalitet i 
appen relaterer til data som er konfidensiell til den brukeren som har registrert den og de 
brukeren ønsker å dele denne dataen med i beitelaget. Om brukeren ikke har en konto 
kan han/hun opprette en ved å klikke på opprett konto. 


For å opprette en konto må brukeren registrere sin epost og motta en magisk lenke. 
Lenken som blir sendt til brukerens epost fungerer som verifisering av eposten, og den 
lar brukeren logge inn for første gang. 
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Fullfør regreringsprosessen ved å fylle ut navn og 
passord 


Fornavn 


Etternavn 


Passord [OJ 


Gå til logg inn Avbryt opprettelse 


Figur 4.26: Registrering av detaljer ved 


opprettelse av profil 


Før brukeren får logge inn må han/hun godkjenne brukervilkårene i tråd med norsk Lov 
om behandling av personopplysninger (GDPR) (Regjeringen, 2019). Om brukeren ikke 
godkjenner vilkårene vil ingen epost bli sendt. Om brukeren velger å godkjenne, vil 


Personvernerklæring 


Personopplysninger vi samler inn 
og behandler 


Grunnleggende informasjon 
Navn. 


Kontaktinformasjon 

E-postadresse. 

Brukeraktivitet 

Oppsynsturer, beitelag, gårder og 
posisjon. 

Brukerhistorikk 

Historikk av oppsynsturer, beitelag og 
posisjon. 

Cookies 

Informasjonskapsler blir brukt for å 
håndtere innlogging, kryptert passord og 
for brukerdefinerte innstillinger i 
applikasjonene. Informasjonskapslene 
har en standard levetid på 60 minutter, 
men utvides ved kontinuerlig bruk av 
tjenestene. 


Hvordan vi bruker 
personopplysningene 


Grunnlag for databehandling 

Data vil bli behandlet basert på samtykke 
fra bruker av applikasjonen. Din 
informasjon vil bli samlet inn, organisert, 
lagret og brukt i applikasjonen i 


Figur 4.27: Brukervilkår for godkjenning 
av opprettelse av profil 


han/hun etter kort tid motta en innloggingslenke til sin epost. 


Etter at innloggingslenken er klikket vil et valideringstoken bli godkjent i applikasjonen 
og brukeren vil bli spurt om å oppdatere sin informasjon. Når dette er gjennomført vil 


brukeren ha mulighet til å logge inn med sin påloggingsinformasjon. 
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4.6.1.2 Hjemskjerm/Feed 

Når en innlogget bruker åpner appen vil de bli møtt 
av Hjem-skjermen som inneholder en Feed av de 
siste aktivitetene i beitegruppene brukeren er 
medlem av. Her kan man se når siste tur ble gått 
og hvem som gikk den. For mer informasjon om 


ein Oppdalsgruppa 
åt pp grupp 


4) 28.5.2022 19:01 hver tur kan turen aksesseres ved å klikke på den, 
* Hans Karlsen å 4 i å 
og brukeren vil bli sendt til en egen side med 
Hedmarksgjengen oversikt over turen. 


23.5.2022 19:04 
Mons Arnesen 


Nederst i hjørnet finner man en knapp som lar 
«344 Oppdalsgruppa bruk Q 
Å m520221750 rukeren starte en ny oppsynstur. Den er lagt på 
g g På Q På p - 
Anna Fredriksen forsiden for at den skal være så lett tilgjengelig 


+94 Oppdalsgruppa som mulig. 
20 13.4.2022 17:03 
* — Anna Fredriksen 


I navigasjonsmenyen nederst på siden kan 
brukeren navigere seg mellom de forskjellige 
hovedsidene i applikasjonen. 


Oppdalsgruppa == B=8=) 
3 gårder, 5 oppsynspersoner 


Figur 4.28: Hjemskjerm i Hedmarksgjengen 1= de 
mobilapplikasjonen 2 gårder, 3 oppsynspersoner 


4.6.1.3 Beitegrupper 

På hovedsiden Beitegrupper får brukeren en 
oversikt over alle beitegrupper han/hun er medi i. 
Hver beitegruppe vises med navn, hvor mange 
oppsynspersoner og gårder det er i hver gruppe. 
Hver gård blir også vist som et ikon på hvert 
element i fargen til gården. Dette er den samme 
fargen gården har på øremerkene til sine sauer og 
velges av bonden selv når en gård blir lagt til i 
gruppen. 


Nederst i hjørnet ser man en knapp tilnærmet lik 
den man så på Hjem-skjermen, men med et annet 
ikon. Ikonet her indikerer at man kan legge til en 


» 
ac 


ny beitegruppe. Strukturen for å legge til en jer Beitegrupper 
beitegruppe er gjort likt som på forrige side for å 
gjøre operasjonen med å legge til et nytt element 
(her beitegruppe eller tur) så intuitiv og 
gjenkjennbar som mulig. 


Figur 4.29: Beitegrupperskjerm i 
mobilapplikasjonen 
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Å | VJ 21.5.2022 17:50 
Statistikk | HE Anna Fredriksen 


Skadde dyr: 0 Turer gått: 3 Oppdalsgruppa 


Døde dyr: 2 Registrerte dyr: 28 188 13.4.2022 17:03 
«344 Anna Fredriksen 


Siste aktivitet Medlemmer 


sg Oppdalsgruppa å Anna Fredriksen 
gd 28.5.2022 19:01 
* Hans Karlsen FEN 
0) Mons Arnesen 
Oppdalsgruppa od 


UO 21.55.2022 17:50 ; 
* — Anna Fredriksen Q Odd Larsen 
354  Oppdalsgruppa EL Hanne Hove 
i 13.4.2022 17:03 


5 Anna Fredriksen lin 
p > Hans Karlsen 


Medlemmer 
Gårder 


Røed 


Anna Fredriksen 


Odd Larsen 

Havstein 
Mons Arnesen 

Jahr 
Hans Karlsen 


Figur 4.30: Øverste del av en Figur 4.31: Nederste del av en 
beitegruppeside i mobilapplikasjonen beitegruppeside i mobilapplikasjonen 


Når en bruker aksesserer en beitegruppe, vil han/hun kunne se all informasjon om 
gruppen. Dette inkluderer statistikk på noen av de viktigste tallene, turer som er gått i 
gruppen, hvilke medlemmer som er med i gruppen og hvilke gårder som er med i 


gruppen. 
Om brukeren er administrator i gruppen, vises det et lite tannhjul øverst i høyre hjørne i 


applikasjonsbaren. Om brukeren klikker på dette tannhjulet, kan brukeren administrere 
gruppen, fjerne turer, fjerne eller legge til medlemmer og fjerne eller legge til gårder. 


Nederst i høyre hjørne finner man igjen knappen for å starte en ny oppsynstur. Dette for 
å gjøre funksjonaliteten så tilgjengelig som mulig og at det kan være naturlig for noen 
brukere å ville starte en tur fra den aktuelle beitegruppen. 
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* Anna Fredriksen 


Statistikk 
Skadde dyr: 0 Turer gått: 3 
Døde dyr: 2 Registrerte dyr: 28 


Medlemmer 


å Anna Fredriksen 


oa 
; Mons Arnesen 


Siste aktivitet 


«353 Oppdalsgruppa 
i 28.5.2022 19:01 
Hans Karlsen 


Odd Larsen 


Hanne Hove 
4 Oppdalsgruppa 
i 21.5.2022 17:50 


* Anna Fredriksen Hans Karlsen 


Oppdalsgruppa 
13.4.2022 17:03 
Anna Fredriksen 


+ 2 Leggtil Medlem 


Gårder 
GS Røed 


Medlemmer 


S -Havstein 


SS Jahr 


å 
Q Odd Larsen 
EL Hanne Hove 


+ Å Legg til Gård 


Figur 4.32: Administrator modus i en Figur 4.33: Administratormodus nedre del 


beitegruppe 


Når administrator-modus er aktivert dukker det opp ikoner ved alle elementer som det er 
mulig å administrere. For medlemmer og gårder finnes det tre alternativer, mulighet for 
å legge til, endre eller slette. Man kan også slette eksisterende turer i gruppen. Når man 
er ferdig med å editere gruppen kan man klikke på krysset som har erstattet tannhjulet i 
øvre høyre hjørne, for å komme tilbake til vanlig modus. 
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Legg til medlem Fjern medlem Endre rolle 


Er du sikker på at du vil fjerne Vil du endre rollen til denne 


Epost dette medlemmet? brukeren? 


Brukeren vil miste tilgang til alle 


Q Sendinvitasjon — turer og informasjon om Member 


beitegruppen 


Avbryt — Fern medlem Avbryt Lagre 


Figur 4.34: Modal for å Figur 4.35: Modal for å Figur 4.36: Modal for å 
legge til medlem fjerne medlem endre et medlem 


Som administrator kan man administrere medlemmene av en beitegruppe. For å legge til 
en bruker som medlem, må man kjenne epost-adressen til brukeren. Systemet vil 
deretter sjekke om brukeren eksisterer og enten sende en invitasjon til brukeren 
tilknyttet eposten eller gi administrator beskjed om at det ikke finnes brukere med denne 
eposten. 


For eksisterende medlemmer, har administrator muligheten til å endre rollen til andre 
medlemmer. Man kan her bytte status på hvert medlem mellom medlem og 
administrator. For å fjerne et medlem må administrator bekrefte dette. 
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Endre farge 


Legg til gård 


Fjern gård 
Gårdsnavn 
Er du sikker på at du vil fjerne 


Gi vene PE 


Avbryt — Fjern gård 
Avbryt — Lagre 


RGB 8 å 
198 50 39 100% 


Avbryt Lagre 


Figur 4.37: Modal for å Figur 4.38: Modal for å Figur 4.39: Modal for å 
legge til en gård fjerne en gård endre farge på en gård 


Skal man legge til en gård skriver man inn navnet på gården og velger hvilken farge 
gården skal ha. Tanken bak valget av farge på en gård er at denne fargen stemmer 
overens med fargen gården benytter seg av på øremerket på sauene. Når man skal 
registrere en saueflokk vil man få muligheten til å registrere fargen på øremerket basert 
på hvilke gårder som er med i beitelaget. 


Dersom man ønsker å fjerne en gård må man først bekrefte at dette er hva man ønsker 
å gjøre, og man kan til enhver tid endre farge på gården skulle dette være aktuelt. 
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4.6.1.4 Profil 


Hanne Hove 


å Hanne Hove 


ke Innstillinger Innstillinger 


Last opp ny tur Last opp ny tur 


Mine invitasjoner Mine invitasjoner 


Logg ut Logg ut 


Figur 4.40: Profilskjerm i Figur 4.41: Notifikasjoner vist i profilen 
mobilapplikasjonen 


Profilskjermen viser navn og bilde til innlogget bruker i tillegg til å presentere ham/henne 
med flere valg. Innstillinger lar brukeren kontrollere sine brukeropplysninger og 
oppdatere dem. Her kan brukeren også slette sin profil. 


Last opp ny tur lar brukeren laste opp en nylig gjennomført tur til databasen. Ettersom 
mye av beiteområdene kan være utenfor dekning vil en tur registreres offline og deretter 
vil brukeren måtte laste den opp til databasen når de får internettilgang tilbake. Om en 
tur venter på å bli lastet opp vil en notifikasjonschip vises her. 


Mine invitasjoner viser invitasjoner brukeren mottar til nye beitegrupper. Om det ligger 
ventende invitasjoner, vil det vises en notifikasjonschip her. Brukeren har også mulighet 
til å logge ut via denne skjermen. 
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Hedmarksgjengen 


Avslå invitasjon 


Ønsker du å avslå invitasjonen? 


Avbryt Avslå 


Figur 4.42: Rediger Figur 4.43: Figur 4.44: Avslå invitasjon 
profilinfo i Invitasjonssiden i modal i mobilapplikasjonen 
mobilapplikasjonen mobilapplikasjonen 


Brukeren kan editere sin profilinformasjon og slette sin profil via innstillinger. Han/hun 
kan også sette et nytt passord om man ønsker å endre dette. Dersom brukeren ønsker å 
slette profilen, vil han/hun måtte bekrefte at hun/han godkjenner at all informasjon 
lagret om han/henne blir slettet og at han/hun vil miste tilgangen til all informasjon i 
applikasjonen inkludert egen registrert data. 


På invitasjonssiden kan brukeren administrere sine invitasjoner og godkjenne eller avslå 
dem. Om brukeren godkjenner en invitasjon vil han/hun bli lagt til i beitegruppen og 
han/hun vil få tilgang til all registrert data i gruppen. Dersom brukeren ønsker å avslå 
invitasjonen, vil han/hun bli spurt om å bekrefte dette før invitasjonen blir fjernet. 
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Slette tur 


Vil du slette denne turen? 
All info registrert vil bli slettet 


Avbryt Slett 


Oppdalsgruppa 
Hanne Hove 31.5.2022 


LAST OPP 


Figur 4.45: Last opp tur siden i Figur 4.46: Modal for å slette en lokalt 
mobilapplikasjonen lagret tur 


For å laste opp en tur etter at man får tilbake internettforbindelsen, må brukeren 
aksessere Lokale turer siden. Her vil turen vises, og man har muligheten til å se detaljer 
om den gjennomførte turen. Kun en tur vil holdes i minnet om gangen så en tur må 
lastes opp før den neste turen kan påbegynnes. Man har også mulighet til å slette turen 
man har gjennomført uten å laste den opp. 
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4.6.1.5 Registrering av oppsynstur 


Oppdalsgruppa v Oppdalsgruppa v 


Last ned kart Kart lastet ned 


Figur 4.47: Start side i mobilapplikasjonen Figur 4.48: Start side for tur med kart 
lastet ned 


Når en bruker har klikket på knappen for Start ny tur vil man bli navigert til Ny tur 
skjermen. Her velger brukeren hvilken beitegruppe han/hun skal gå tur for. I tillegg blir 
brukeren vist et utsnitt av kartet sentrert på brukerens posisjon som man kan flytte 
rundt og zoome i. For at brukere skal kunne gå turer i områder som faller utenfor 
internettdekning, må det lastes ned et kartutsnitt før brukeren starter turen. Ved å klikke 
på last ned kart vil det utsnittet av kartet som vises på skjermen lastes ned og skrives til 
lokalt minne på telefonen. Når kartutsnittet er lastet ned vil det dukke opp en knapp 
nederst i høyre hjørne som lar brukeren gå videre og starte den nye turen. 
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Legg til hendelse/notat 


Logg 


w Fullfør tur 


5) Avbryt tur 


Figur 4.49: Hovedsiden for en startet tur i Figur 4.50: Menyen under en startet tur i 
mobilapplikasjonen mobilapplikasjonen 


Når turen er startet vil man komme til hovedsiden for oppsynsturen. Herfra kan man 
følge med på hvor man er i kartet og planlegge turen sin. I toppmenyen finner man to 
knapper. Meny-ikonet til venstre åpner en slide-out-meny som viser metadata om turen 
som hvor lang tid man har brukt og hvor langt man har beveget seg. Herfra kan man 
også registrere hendelser eller notater underveis på turen og fullføre eller avbryte turen 
man er på. 


Nederst til høyre kan man igjen identifisere en knapp. Denne gangen representerer den 
muligheten til å registrere en flokk i kartet når oppsynspersonen observerer sauer 
underveis i turen. 
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Rovdyr Rovdyr 
Legg til hendelse/notat 


2:34 Jerv 
Description 


Jerv observert i skogkanten. 
2:35 Lam skadet 


2:36 Gjerdesjekk 


217 


Jerv observert i skogkanten. 


Fullfør tur 


Avbryt tur 


Figur 4.51: Registrering av Figur 4.52: Hendelser lagt Figur 4.53: Redigering av 
en hendelse i til i loggen en hendelse 
mobilapplikasjonen 


Dersom brukeren ønsker å registrere en hendelse vil han/hun havne på Registrer 
hendelse skjermen. Her kan han/hun legge inn data om hendelsen og registrere hvilken 
type hendelse det er. Alternativene brukeren kan velge mellom er: 


- Notat - Skadet dyr 
- Dødt dyr - Rovdyr 
- Annet 


Hver kategori har et eget ikon og farge for å gjøre dem enkle å identifisere. Når en 
hendelse blir lagret vises den i logglisten i menyen. Herfra kan brukere fjerne eller 
redigere hendelsene ved behov. 


Om brukeren ønsker å redigere en hendelse vil hendelsen vises på den samme siden og 
brukeren kan redigere de ønskede feltene. I bildet over er det blitt lagt til bilder av den 
registrerte jerven. Hendelser kan også slettes fra menyen ved å bekrefte at man ønsker 
å gjennomføre denne handlingen i en modal. 
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Anna Fredriksen 
April 13, 2022 5:03:43 PM 


Anna Fredriksen 
May 21, 2022 5:50;05 PM 


Hans Karlsen 
May 28, 2022 7:01:49 PM 


Figur 4.54: Meny for valg av tidligere Figur 4.55: Tidligere tur vist i kartet 
turer 


Ved å klikke på tannhjulet i toppmenyen til høyre får brukeren tilgang til å velge tidligere 
turer å vise i kartet. Den tidligere turen blir tegnet inn inkludert hvor oppsynspersonen så 
sauer og hvor det ble registrert hendelser underveis. Dette kan være nyttig informasjon 
om en annen oppsynsperson skal undersøke en hendelse som er blitt registrert eller om 
man ønsker å se hvor sauene ble sett sist noen gikk tur. 


Dersom man ikke ønsker å se turen i kartet lenger, kan man klikke den bort igjen i 
menyen. Det er også mulig å vise flere tidligere turer i kartet samtidig. 
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Figur 4.56: Posisjonering av en flokk i Figur 4.57: Registrering av en flokk i 
kartet kartet 


Ved å klikke på knappen nede til høyre blir man tatt inn i registreringsmodus for 
observerte sauer. Knappen skifter farge til rød for å indikere at om man vil avbryte 
prosessen, kan man gjøre dette ved å klikke på knappen en gang til. Når knappen er rød, 
kan brukeren fritt plassere flokken han/hun har observert i kartet hvor flokken er. 
Flokkmarkøren ser ut som en sau og er flyttbar helt til brukeren velger å gå videre i 
registreringen. 


Når brukeren har plassert flokken et sted i kartet, splitter knappen seg i to og gir 
brukeren valget mellom å kansellere registreringen av flokken og å gå videre i 
registreringsflyten. Dersom brukeren velger dette, vil han/hun ha mulighet til å registrere 
flere detaljer om flokken. 
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Registrer dyr Registrer dyr 


Totalt: 4 Totalt: 4 


Grå sau: 0 Brun sau: 4 | Grå sau: 0 Brun sau: 4 


Sort sau: 0 Grått lam: 0 Sort sau: 0 Grått lam: 0 


Brunt lam: 0 Sort lam: 0 Brunt lam: 0 Sort lam: 0 


Figur 4.58: Kikkertmodus for registrering Figur 4.59: Gjennomføring av registrering 
av Sau av sauer i kikkertmodus 


Ettersom domeneeksperten spesifiserte et behov for registrering av sau, mens 
oppsynspersonen holder kikkerten opp til øynene på grunn av vanskeligheter med å 
registrere saueflokker på avstand, ble det utarbeidet to forskjellige måter å registere 
sauer på. 


Over kan man se den endelige løsningen på registrering av sauer på avstand, 
kikkertmodus. Dersom flokken brukeren registrerer, er mer enn 30m unna 
oppsynspersonen vil kikkertmodus vises automatisk når en flokk skal registreres. I denne 
modusen vises en stor sveipeknapp for å gjøre det enkelt for brukeren å legge til eller 
fjerne sauer uten å se på skjermen. Under registrering på denne siden er det benyttet 
«Text to speach» verktøy for å lese opp for brukeren hvilken type sau det er han/hun 
registrerer for øyeblikket. Når brukeren legger til eller fjerner sauer leses det opp hvor 
mange sauer av den typen som nå er registrert. På denne måten kan brukeren registrere 
sauer uten å se på skjermen og få feedback via høyttaleren på telefonen. 


Brukeren sveiper til høyre og venstre for å registrere antall sauer og nedover og oppover 
for å navigere mellom forskjellige sauetyper. Ettersom brukeren beveger seg nedover i 
listen, vil den sauetypen man registrerer for øyeblikket bli fremhevet i listen over 
knappen. Når brukeren har kommet gjennom flyten, vil han/hun kunne sveipe for å 
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fullføre flyten. Han/hun vil da bli ført over til manuellmodus hvor han/hun kan registrere 
flere detaljer om sauene eller fullføre registreringen av flokken. 


På grunn av at det er svært vanskelig å identifisere detaljer på lang avstand er 
kikkertmodus begrenset til å kunne registrere antall sauer av hver farge, ettersom det 
ofte er den eneste informasjonen som er mulig å observere. Noen ganger kan også farge 
være vanskelig å registrere. Det er derfor også mulig å kun registrere et totalt antall 
sauer i kikkertmodus og deretter ferdigstille registreringen ved å navigere til 
manuellmodus via knappen i høyre hjørne. 


- Q- 


Registrer dyr 


BRUN: Q 0 
SORT: eo 0 


Sau - Grå 

TAG: 
Ukjent 

SLIPS: 
Ukjent 


Kommentar om flokken... 


Figur 4.60: Manuell registreringsmodus Figur 4.61: Registrering av dyr i manuell 
for sau modus 


Dersom oppsynspersonen er nærmere en flokk enn 30m eller har fullført registrering av 
sau i kikkertmodus, vil han/hun bli navigert til manuellregistrering av en flokk. Er det 
allerede registrert sauer i kikkertmodus, vil sauene registrert vises i det manuelle 
brukergrensesnittet. Her har man tilgang til å registrere antall sauer av hver type ved 
hjelp av pluss og minus knapper i tillegg til å kunne registrere flere detaljer om de 
sauene som er blitt observert. Ved å klikke på Legg til flere detaljer vil hver sau bli vist 
som en entitet på skjermen og man kan registrere flere detaljer om hver enkelt sau. 
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Ikonet øverst i hjørnet på en saueentitet indikerer hvilken farge sauen har, men 
informasjonen finnes også i tekstformat på venstre side av entiteten. 


Man kan alltid bytte tilbake til kikkertmodus ved å klikke på øyeikonet øverst i høyre 
hjørne av skjermen. Man kan også avbryte registreringen av flokken ved å benytte 
knappen øverst i venstre hjørne. 

p gi - 


Registrer dyr 


- Ge 


Registrer dyr 


BRUN: Q 0 
SORT: O 0 


| oc 
BRUN: Q 0) Q 1 
SORT: eo) 0 eo 0 


O Røed O Rød 


O Blå 
Gul 


O Grønn 


O Havstein 


OG Jahr 


Ukjent 
DLIFD: 


Ukjent Ukjent 


Lam - Brun Lam - Brun 


TAG: 
Ukjent 


TAG: 
Ukjent 


Figur 4.63: Registrering av slipsfarge på 


Figur 4.62: Registrering av hk 


øremerke på en sau 


Når en oppsynsperson står nær nok en sau til å observere flere detaljer om sauen enn 
fargen på ullen, vil han/hun ha mulighet til å registrere disse på sauen. To av de 
relevante tingene å registrere er slipsfarge og farge på øremerket. Fargen på øremerket 
avgjør hvilken gård i beitelaget sauen tilhører. I dropdown-menyen, som er åpnet på 
bildet over til venstre kan man se at det i denne beitegruppen er tre gårder som har hver 
sin farge tilknyttet seg. Det er også mulig å velge ukjent, skulle en oppsynsperson ønske 
å benytte seg av manuellmodus uten å ha mulighet til å observere merket til sauen. 


I motsetning til øremerke som finnes på alle dyr på utmarksbeite er det kun voksne 
sauer som bærer slips. Slipsene indikerer hvor mange lam sauen ble sluppet på beite 
med og kan være svært relevant å registrere for å observere om det mangler lam i 
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flokken. Fargene på slipsene er forhåndsdefinert i applikasjonen er basert på standarder 
fastsatt av Norsk Sau og Geit (NSG). Valg av slips kan sees i bildet over til høyre. Også 
her er det mulig å velge ukjent i tilfelle oppsynspersonen ikke kan observere fargen på 
slipset. 


3:30  * 


Registrer dyr 


Legg til kommentar 


Kommentar om sauen... 


Lagre 


Lam - Brun 


TAG: 


Figur 4.64: Legg til kommentar på en sau Figur 4.65: En sau markert skadet og en 
kommentar på et lam 


For hver sau eller hvert lam registrert, er det mulig å legge til en kommentar eller 
markere dyret som skadet. Desom det er lagt til en kommentar på en sau vil det vises et 
ikon ved siden av fargemerket for å indikere at det er mer informasjon lagt til dette 
dyret. Om sauen er markert skadet vil den grønne skadet knappen bli rød, og det vil bli 
lagt til et eget ikon for å indikere markeringen av sauen ved siden av fargemerket. 
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BRUN: Q 0 
SORT: Q 0 


Fullfør tur 


Er du sikker på at du vil fullføre 
turen? 


Tilbake Bekreft 


Kommentar om flokken 


Figur 4.66: Legg til bilde av Figur 4.67: Flokk i kart Figur 4.68: Fullfør tur 
en flokk etter registrering modal 


Om oppsynspersonen ser noe unormalt eller ønsker å legge til bilder av flokken, kan 
dette gjøres ved å klikke på legg til bilder knappen og velge et bilde fra telefonens 
bibliotek. Når en flokk er ferdig registrert kan man lagre flokken og den vil vises i kartet 
som i Figur 4.67. Brukeren står nå fritt til å legge til en ny flokk eller hendelse. 


For å fullføre turen kan brukeren åpne turmenyen igjen og benytte fullfør tur knappen. 
Denne menyen er vist i Figur 4.68. Brukeren vil få opp en modal hvor han/hun må 
bekrefte at turen er ferdig, før han/hun blir navigert til en oversikt over den 
gjennomførte turen hvor man kan gå igjennom dataen som er blitt registrert. 
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4.6.1.6 Gjennomført tur 


& Hans Karlsen 
8.14.2022 19:14 


Beitegruppe * Oppdalsgruppa 
3 Vy, 


Flokk 


Tid Flokk 1 
00:12:26 J 


Antall lam Flokk 2 


Flokk 3 
Flokker 
FOR I 
Flokk 2 
Flokk 3 
Vis alle flokkene 


Flokker Hendelser 1 
Flokk 1 Den 


Flokk 2 Vis alle hendelsene 
2 sau 


Figur 4.69: Oversikt over Figur 4.70: Oversikt over Figur 4.71: Oversikt over 
en gjennomført en gjennomført alle registrerte flokker 
oppsynsrunde oppsynsrunde 


Når en tur er gjennomført eller en bruker ønsker å se detaljer om en tidligere 
gjennomført tur enten fra Feed, via en beitegruppe eller før den blir lastet opp til skyen 
vil brukeren navigeres til Tur-skjermen. Her vises all data registrert gjennom den 
gjennomførte turen. Brukeren vil kunne se hvem som har gjennomført turen, når den ble 
gjennomført og for hvilken beitegruppe. Man kan også se informasjon om hvilken løype 
som ble gått, hvor det ble observert flokker og hvor det ble registrert hendelser. Det er 
et eget panel for overordnet statistikk om turen. 


Under statistikken for turen, finnes det en oversikt over alle flokkene og hendelsene som 
ble observert på turen. Her vises de tre første hendelsene og flokkene som ble registrert. 
Om brukeren ønsker å se alle flokker eller hendelser som ble registrert han han/hun 
klikke på «Vis alle hendelser» eller «Vis alle flokker». Oversikten over alle flokker og alle 
hendelser ser forveksling lik ut. Listen over alle flokker er vist i figur 4.71. 
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Antall lam - : 
3 3 Kategori 


Død Sau Dødt dyr 


Skader Klokkeslett 
1 19:10 Bilder Klokkeslett 


1 19:13 
Kommentar 
Kommentar 


Død sau, litt ull 


mulig forårsaket av rovdyr 
Dyr 


Lam 1 
Grå * Jahr 


Lam 2 


Brun * Jahr 


Figur 4.72: Oversikt over en registrert Figur 4.73: Oversikt over en registrert 
flokk hendelse 


Dersom brukeren vil se flere detaljer om en registrert flokk eller en hendelse, kan 
han/hun trykke på flokken eller hendelsen. Dette vil navigere brukeren til flokk eller 
hendelsessiden respektivt. På denne siden kan brukeren se informasjon om hvor flokken 
eller hendelsen ble registrert på oppsynsrunden, hva som ble registrert av data og 
statistikk for flokken eller hendelsen. Ved å klikke på en sau eller et lam under en flokk, 
kan brukeren også få se om det finnes notater på den aktuelle sauen. Om dette finnes, 
vil det markeres med et ikon ved siden av ikonet som viser dyrets gårdtilhørighet via et 
gårdikon i gårdens farge. Her vil det også vises et ikon om dyret er markert som skadet 
under turen. 


75 


4.6.2 Webapplikasjon 

Webapplikasjonen tilbyr brukeren funksjonalitet for å opprette, administrere og slette sin 
brukerprofil, mulighet til å evaluere tidligere gjennomførte turer i beitegruppene og 
mulighet for å generere rapporter over beitesesongen. Webapplikasjonen fungerer i stor 
grad som et oversiktsverktøy hvor man kan utforske detaljene rundt de gjennomførte 
turene den sesongen. I seksjonen under vil denne funksjonaliteten bli presentert i større 
detalj. 


4.6.2.1 Signup 


Figur 4.74: Innlogginsside i webapplikasjonen 


Når en bruker åpner webapplikasjonen, vil han/hun se innloggingsskjermen til 
applikasjonen. All funksjonalitet i applikasjonen ligger bak innlogging ettersom dataen 
som vises er knyttet til brukere og registreringer gjennomført av dem og andre tilknyttet 
beitelag. En bruker vil måtte benytte seg av sin epost og passord for å logge inn. Om 
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han/hun ikke har en bruker, kan han/hun opprette en ved å klikke på «Opprett ny 
profil». 


Beiteweb x4 


Fortsett via den magiske linken sendt til deg på 
epost 


Figur 4.75: Opprettelse av profil i webapplikasjonen 


For å opprette en ny profil må eposten til brukeren verifiseres. For å gjøre dette benytter 
systemet seg av en magisk lenke som sendes til brukerens epost. Brukeren må klikke på 
lenken i sin epost for å kunne fortsette registreringen. Dette foregår på samme måte 
som i mobilapplikasjonen. 


Fullfør din registrering 


Din epost 


Fornavn 
Odd 
Etternavn 


Larsen 


Passord 


Figur 4.76: Fullførelse av opprett profil i webapplikasjonen 


77 


For at brukeren skal kunne benytte seg av sin nye konto må han/hun fullføre profilen sin. 
Fornavn og etternavn er valgfritt, men passordet må registreres. Om brukeren lar 
passord feltet stå tomt, om passordene ikke er like eller passordet er kortere enn seks 
karakterer, vil det vises en feilmelding til brukeren. Når brukeren er klar til å fullføre sin 
profil kan han/hun klikke på fullfør knappen. 


4.6.2.2 Dashbord 


Dashbord 
Oppdalsgruppa v 2022 v 
Turer gått Døde sauer Rovdyr sett Skadde sau 
Odd Larsen 3 2 2 
Medlemmer 
æ Anna Fredriksen 
Årets turer 
pi vik EE GG veven 
B 28.5.2022 Hans Karlsen 7 å & EG 
Rapport 
1.5.2022 1 OG 
& Hans Karlsen 
13.5.2022 Anna Fredriksen 6 [0] 
or) Odd Larsen 
Gårder 
Å roed 
Havstein 
År som 


Profil 


Figur 4.77: Hjemsiden i webapplikasjonen 


Når en bruker er logget inn vil han/hun havne på Dashbord-siden av applikasjonen. På 
denne siden kan brukeren bla gjennom sine beitegrupper og tidligere sesonger via 
nedtrekks menyen i høyre hjørne. Øverst på siden finnes det på samme måte som i 
mobilappen, en statistikkseksjon som viser noen av de mest interessante tallene for 
beitegruppen så langt i den valgte sesongen. Dette for at det skal være enkelt å få en 
generell oversikt over hva som har skjedd i gruppen den aktuelle sesongen. Basert på 
hvilken gruppe og sesong som er valgt vil også «Årets turer» seksjonen populeres med 
de gjennomførte turene i gruppen den sesongen. I Figur 4.77 kan man se 3 turer. Hver 
tur beskrives med dato gjennomført, hvem som har gjennomført turen og hvor mange 
sauer som ble observert under turen. I tillegg har hver tur en oversikt over hendelser 
som har blitt registrert på turen. Ikonene for å illustrere hendelsene er de samme som er 
benyttet i mobilapplikasjonen, slik at de skal være intuitive for brukeren og enkle å 
forholde seg til. Til høyre på Dashbordet finner man en oversikt over alle medlemmer og 
gårder i gruppen. Til venstre finner man en meny som gjør det enkelt å navigere videre i 
applikasjonen. For å se mer informasjon om en gjennomført tur kan brukeren klikke på 
den aktuelle turen i listen. 
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4.6.2.3 Turoversikt 


Oppdalsgruppa 


Vis beitekvalitet i kart Tegnforklaring Hans Karlsen 
Flokker 


Registreringsposisjon  Hendelsesposisjon  Flokkposisjon 


Odd Larsen 


2 Sau 3 Lam 19:05:44 


2 Sau 3 Lam 19:08:41 


Rapport 3 Sau 3 Lam 19:10:03 


Hendelser 


Dødt dyr1 
Død Sau 19:13:26 


Flokk I Antall sau Antall lam Beskrivelse: 
2 3 
Skadde dyr Klokkeslett 
0 19:05:44 
Saul —% Forge: Grå Sau2 Farge: Brun 


G I Slips: Ukjent 3 E Slips: Ukjent 
Tag: Ukjent Å Tag: Ukjent 
lam1 =æ Brun lam2 = Brun lama Brun 


Figur 4.78: Oversikt over en gjennomført tur i webapplikasjonen 


Når brukeren klikker på en tur i Årets turer-oversikten blir han/hun navigert til en ny side 
som viser en oversikt over turen og registrerte detaljer. Hovedfokuset på denne siden, er 
kartet som viser en oversikt over hvor oppsynspersonen beveget seg i terrenget. Her 
vises også hvilke flokker og hendelser han/hun har registrert og hvor i kartet de er 
plassert. En beskrivelse av de forskjellige elementene man kan observere i kartet finnes 
over kartelementet. Dette inkluderer registreringsposisjonen til oppsynspersonen når en 
flokk ble registrert, flokker som ble observert og hendelser som ble registrert. Man har 
også muligheten til å vise beitekvalitet i kartet og se en tegnforklaring av hva de 
forskjellige markeringene av beiteområdet betyr. 


Til venstre finner man en liste med oversikt over registrerte flokker og hendelser på 
turen. Ved å klikke på en flokk eller en hendelse vil detaljer om flokken eller hendelsen 
vises nederst på skjermen. 
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Oppdalsgruppa 


Hans Karlsen 


v 
Registreringsposisjon Hendelsesposisjon —Flokkposisjon 
GH X f - Flokker 


Flokk 1 
2 5au 3 Lom 19:05:44 


Flokk 2 
2 50u 3 Lom 19:08:41 


Flokk 3 
3 Sau 3 Lam 19:10:03 


Hendelser 


Dødt dyr I 
Død Sau 19:13:26 


Flokk 1 


Sau] Farge: Grå Sau2 Ø Farge: Brun 


Figur 4.79: Info om en registrert flokk vist i kartet 


Om en bruker ønsker å se detaljer om en flokk i kartet er det mulig å klikke på flokken 
og få opp noen detaljer om hvor mange dyr som ble registrert i flokken og når den ble 
observert. Dette kan være nyttig når en oppsynsperson planlegger en ny tur eller ønsker 
å forstå bevegelsesmønsteret til sauer på beite. Det tegnes opp en linje mellom 
registreringsposisjonen til oppsynspersonen og den registrerte flokken for å bedre 
illustrere sammenhengen mellom posisjonene og hvor oppsynspersonen stod når 
han/hun så sauene. 


Flokker 


Flokk 1 
25au 3 Lam 19:05:44 
Flokk 2 
2Sau 3 Lam 19:08:41 
Flokk 3 
3 Sau 3 lam 19:10:03 
Hendelser 
Dødt dyr 1 
Å Død Sau 1913:26 
f a N 
| 9 
W% « 
G i N/A K/N dr 
Flokk 3 Boskivelse: 
Saul ØY Farge: Grå Sau2 Farge: Grå Sau3 —Ø Farge: Brun 
3 Å Slips: Rød 9 å Slips: Blå G i Slips: Gul 
Å Tog: Jahr Ø Tog: Jahr Ø Tog: Jahr 
Lam1 % farge Grå lam2 øm Forge Brun Lam3 ø* farge Brun 


3 Ø 103 Jahr 3 Å og Jahr 3 Ø 105 Jahr 


OBS! Lammet er markert skadet 


Figur 4.80: Oversikt over en flokk registrert på en tur i webapplikasjonen 
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Når en flokk er valgt vil den vises nederst på skjermen med alle detaljer som er registrert 
om den. Hver flokk viser et statistikkpanel som presenterer noe av den mest interessante 
infoen til brukeren. Utover dette vises hvert dyr som et eget kort i flokken. Hver sau har 
data registrert om seg som vil vises på kortene. Om sauen er skadet vil dette markeres 
med et rødt ikon i hjørnet av kortet og teksten «OBS! Lammet/Sauen er markert som 
skadet» vil vises. Om det finnes noen kommentar om en aktuell sau vil dette også vises i 
seksjonen under skadeteksten. 


I de tilfellene hvor det er tatt bilder av flokken vil disse vises under listen av lam og 
sauer. Dette er likt for hendelser, et eksempel på dette vises i figur 4.81. 


Vis beitekvalitet i kart Tegnforklaring Hans Karlsen 


Registreringsposisjon  Hendelsesposisjon — Flokkposisjon 
am Flokker 


GØ fr / SNØ 


Flokk 1 
2 Sau 3 Lam 19:05:44 


Flokk 2 
2 Sau 3 Lom 19:08:41 


Flokk 3 
3 Sau 3 Lom 19:10:03 


Hendelser 


Dødt dyr I 
Død Sau 19:13:26 


Død Kategori Beskrivelse: 
Dødt dyr Død sau, litt ull mulig forårsaket av rovdyr 
Sau 
Klokkeslett 
19:13:26 


Figur 4.81: Oversikt over en hendelse registrert på en tur i webapplikasjonen 


Om en hendelse er valgt vil detaljer som er registrert om den vises nederst på skjermen 
på samme måte som en flokk. Her vises tittel og kategori samt en eventuell beskrivelse 
av hva som har hendt. Om det finnes bilder registrert på turen vil disse vises nederst. 
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Oppdalsgruppa 


Vis beitekvalitet i kart (1) Tegnforklaring Hans Karlsen 
Tegnforklaring beiteoversikt 


(0 Dyrka mark 


19:05:44 
8 eitevollar og hagemarkskog | 


1 Mindre godt beite 
| OG Godtbeite 
OD svært godt beite 


19:08:41 


3 Lom 19:10:03 


Hendelser 


Dødt 


dyr 
Død Sau 19:13:26 


Beskrivelse: 
Død sau, litt ull mulig forårsaket av rovdyr 


Figur 4.82: Oversikt over beitekvalitet i kart i webapplikasjonen 


Det er mulig å visualisere beitekvalitet i kartet ved å benytte seg av toggle knappen. 
Data om beitekvalitet er kun tilgjengelig i deler av Norge hvor dette har blitt rapportert 
inn og legges oppå det eksisterende kartet som et eget kartlag. Dataen er hentet inn fra 
NIBIO (NIBIO, 2021). Om brukeren ønsker en beskrivelse av hva de forskjellige fargene i 
beitekvalitetskartet betyr kan han/hun benytte seg av tegnforklaringsknappen. 
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4.6.2.4 Rapport generering 


Rapport Rapport 
Beitegruppe Velg gruppe v Beitegruppe Oppdalsgruppa v 
Odd Larsen Odd Larsen 
Sesong gen sesonge! v Sesong 2022 v 
Generer rapport 
3 G 
Dashbord Dashbord 


Rapport Rapport 


Profil Profil 


Figur 4.83: Valg for generering av rapport Figur 4.84: Valgte parametere for 
i webapplikasjonen generering av rapport i webapplikasjonen 


Når en bruker ønsker å generere en rapport over det gjennomførte oppsynet vil han/hun 
ha muligheter for å velge hvilken beitegruppe og hvilken sesong han/hun ønsker å 
generere rapport for. Typisk vil dette være noe en bonde gjør ved slutten av en 
beitesesong for å sende inn dokumentasjon på gjennomført oppsyn til miljødirektoratet. 
Både beitegruppe og sesong må være valgt for å få generert en rapport. 
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Tofeaffa-0019-4855-8192-0877b440de7a 


Generert 2.6.2022 
av Odd Larsen 


Oppsynsrapport utmarksbeite 


Sesong 2022 


Metadata 
Tilsyn gjennomført I beitelag? 


Deltakende gårder 


Oppsynspersoner 
Samlet oppsynstid: 


Oppsynsturer gjennomført: 


Oppsummering av sesongens oppsyn 
Funn av døde dyr: 


Observerte rovdyr. 


Observerte sauer: 


Turer 
Tur 1 
Dato: 28.5.2022 


Oppsynsperson: Hans Karlsen 


Tid brukt: 


Flokker sett: 


Hendelser registrert: 

Hendelser: 

Hendelse 1 Kategori 
Dødt dyr 


Figur 4.85: Første side av en generert rapport i webapplikasjonen 


Tofeaffa-0019-4855-8192-0877b440de7a 


Turer 
Tur 1 
Dato: 28.5.2022 


Oppsynsperson: Hans Karlsen 


Tid brukt: 


Flokker sett: 


Hendelser registrert: 
Hendelser: 
Hendelse 1 


Beskrivelse Død sau, litt ull 
mulig forårsaket av rovdyr 


Tid observert Posisjon 


19:08:32 63.4324 10.413 
Tid observert Posisjon 


19:08:39 63.4326 10.414 


Tid observert Posisjon 
18:10:01 63.4329 10.4145 


Figur 4.86: Andre side av en generert rapport i webapplikasjonen 


Når en bruker klikker på generer rapport vil han/hun få generert en pdf-fil med all 
informasjon om de gjennomførte oppsynsturene som er relevant for miljødirektoratet å 
anskaffe informasjon om for å kunne vurdere en erstatningssak for tap av sau. Valget av 
hvilken informasjon som er relevant er basert på bondelagets veileder for søknader om 
erstatning for tap av sau (Norges Bondelag, 2020). Først i dokumentet blir generell 
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statistikk og metadata om beitelaget og sesongens oppsynsturer presentert. Etter dette 
presenteres sesongens turer med registrerte flokker og hendelser. 


4.6.2.5 Profil 


Profil Profil 
Epost Oddlarsenøgmail.com L Oddlarsen22gmail.com 
Odd Larsen Odd Larsen EROS k på p 
Fornavn Odd 
Fornavn Odd 
5 Etternavn Larsen GE 
Dashbord Dashbord Etternavn Larsen 
Passord Show B 
Rapport Rapport Passord vea Show 
Oppdater profil 
Passord må ha 6 karakterer eller mer 
Logg ut Oppdater profil 
Logg ut 
Profil Profil 
Figur 4.87: Oversikt over profil i Figur 4.88: Oversikt over feilmeldinger i 
webapplikasjonen profilsekjsonen i webapplikasjonen 


Profilsiden i webapplikasjonen lar en bruker endre informasjonen som er registrert om 
dem. Om bruker forsøker å oppdatere informasjonen sin med en ugyldig epost eller et 
ugyldig passord vil brukeren få en feilmelding. 


4,7 Tilgjengelighet 


4,7.1 WCAG krav 

WCAG eller Web Content Accessibility Guidelines er en internasjonal standard for 
webutvikling som inneholder kriterier for å utvikle webinnhold for alle. Kriteriene 
beskriver hvordan man gjør webinnhold mer tilgjengelig for mennesker med 
funksjonsnedsettelser og bidrar til å fremme utvikling av innhold tilgjengelig for alle 
(W3C Web Accessibility Initiative WAI, 2005). WCAG 2.0 ble først utviklet i 2008 og i 
2013 ble det vedtatt ved norsk lov at utviklede IKT løsninger i Norge som retter seg mot 
norske brukere, benytter web/app som en viktig kanal for å tilby tjenester og har et 
nettsted eller app som er knyttet til virksomhetens alminnelige funksjon skal følge WCAG 
standarden og oppfylle 35 av 61 suksesskriterier (uutilsynet) 
(administrasjonsdepartementet, 2013). Reglene er strengere for virksomheter i offentlig 
sektor enn i privat da offentlig sektor også må følge EN 301 549 v3.2.1 som er en 
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europeisk standard som også inkluderer kriteriene i WCAG 2.1. Dette er enda ikke t krav 
for private leverandører (uutilsynet). Suksesskriteriene i WCAG 2.0 standarden er delt 
inn i tre nivåer kalt A, AA og AAA. Ingen av kravene fra kategori AAA er lovpålagt private 
leverandører i Norge, men det er positivt om løsningen likevel oppfyller krav i AAA 
kategorien (uutilsynet). 


WCAG 2.0 har ikke egendefinerte kriterier for mobilapplikasjoner, men det er spesifisert 
at om applikasjonen behøver internettilgang etter at den er blitt lastet ned til telefonen 
regnes appen som en nettløsning og det kreves derfor at disse er universelt utformet på 
lik linje med webapplikasjoner (uutilsynet). Teamet har gjennom utviklingsprosessen 
arbeidet for å følge suksesskriteriene i WCAG 2.0 standarden og dermed også for å være 
i tråd med norsk lov og sette fokus på universell utforming og tilgjengelighet. 


Eksempler på fokuset som har blitt holdt på tilgjengelighet gjennom utviklingsperioden er 
at alle elementer som er interaktive i webapplikasjonen kan fokuseres ved hjelp av 
navigering med tastatur. I tillegg er alle interaksjonselementer gitt annen farge eller 
utforming når en bruker holder over dem med musepekeren. På denne måten skal det 
være enkelt å se hvilke elementer som er interaktive og være enklere å navigere i 
applikasjonen. 


For fremvisningen av registrerte sauer i både webapplikasjonen og mobilapplikasjonen 
har det blitt lagt vekt på at fargen til sauen, fargen på slipset, eller øremerket aldri kun 
vises ved hjelp av fergede ikoner eller elementer, men alltid er beskrevet med tekst i 
tillegg. Dette er for å gjøre det enklere for brukere som benytter seg av skjermlesere, 
fargeblinde og andre brukere som ikke med enkelhet kun forholder seg til farger som 
indikasjon på informasjon. 


4,7.2 Analyse av WCAG 2.0s suksesskriterier 

I tabellen under presenteres de fem første suksesskriteriene i WCAG 2.0 og hvor godt det 
utviklede systemet imøtekommer dem. Dette er kun et utdrag av analysen og den 
fullstendige suksesskriterieanalysen kan sees i vedlegg R. Tabellen er fargekodet etter 
hvor godt hvert suksesskriterie er oppfylt. Grønn indikerer fullstendig oppfylt, gul 
indikerer at det eksisterer enkelte mangler og rød indikerer at kravet ikke er 
imøtekommet. For at systemet skulle ha kunne blitt lansert må de kriteriene som ikke er 
oppfylt per i dag utbedres. Gjennom suksesskriterieanalysen ble systemet funnet å 
imøtekomme 30 av suksesskriteriene, imøtekomme 2 av suksesskriteriene delvis og å 
ikke imøtekomme 3 av suksesskriteriene. Suksesskriteriene i analysen er hentet fra 
Uutilsynets presentasjon av WCAG 2.0 standarden (uutilsynet). 
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Suksesskriterieanalyse av WCAG 2.0 


Nummer | Kategori Kriterie Grad av oppfyllelse 
Til A Ikke-tekstlig 
innhold 
1.2.1 A Bare lyd og bare 
video 
12,2 A Teksting | Det er ingen videoklipp i mobil 
1.3.1 A Informasjon og 
relasjoner 
1.3.2 A Meningsfylt 
rekkefølge 


Tabell 4.9: Utdrag av suksesskritereanalysen av WCAG 2.0. Full analyse finnes i vedlegg 


R. 


87 


De kravene som per i dag ikke er oppfylt består av «Endring av tekststørrelse», «Hoppe 
over blokker» og «Flere måter å navigere på». Endring av tekststørrelse omfatter at 
brukeren skal kunne forstørre teksten opp til 200% uten at løsningen blir utfordrende å 
bruke. Mobilapplikasjonen har i dag noen tekstfelter som ikke tåler dette. Hoppe over 
blokker er ikke relevant for mobilapplikasjonen, men en bruker skal kunne hoppe over 
info for å komme til den viktigste informasjonen på en nettside. Per i dag er det ikke lagt 
inn slike løsninger i Beiteweb. Flere måter å navigere på, siker til at brukeren skal kunne 
bevege seg rundt i systemets hierarki på flere måter enn ved bare en meny. Per i dag er 
ikke dette noe som er mulig i Beiteweb. 


Årsaken til at disse kravene ikke er oppfylt er et fokus på å ferdigstille løsningen innenfor 
de tidsrammene som følger prosjektet. Disse punkene måtte ha blitt utbedret for å kunne 
lansere systemet som en komplett løsning. For en mer utfyllende beskrivelse av alle 
suksesskriteriene inkludert disse tre, se den fullstendige analysen i vedlegg R. 


4,8 Utviklingsteknologi 


4,8.1 Systemarkitektur 

For å få systemet til å fungere og være tilgjengelig på flere plattformer ble det utarbeidet 
en systemarkitektur som skulle være enkel å koble tjenester på etter behov. Under 
presenteres en skissering på arkitekturen som er utarbeidet og hvordan de forskjellige 
tjenestene er satt sammen. 


BeiteMaster 


Gill Å Beiteweb webserver 

(heroku) 

Postgres udi 
Sal 


V 


Å 
| Hente beiteweb applikasjon | | HTMLU/Tavaseript 


Hent/Sende beite-/brukerdata 


Hent/Sende beite-/brukerdata 
> 


Beiteloggen ; Supabase 
(Flutter mobilapp) ISON (Baas) 


Beiteweb 
(Nettleser) 


UDEN DDD =DDNNUVDDDDLKHNM 


Figur 4.89: Systemarkitektur for Beitemaster 


ISON 


Systemet består av tre tjenester; mobilapplikasjon, backendservice og webapplikasjon. 
Beiteloggen 

Beiteloggen er en mobilapplikasjon for Android og iOS utviklet i Flutter. 

Supabase 


Supabase fungerer som backend for BeiteMaster systemet, og er primærkilden til data i 
begge applikasjonene. Løsningen har automatisk genererte API'er basert på de 
utarbeidede datamodellene i databasen. Supabase bygger på PostgresSQL og kjører 
POStGREST som gjør at Postgres databasen dermed blir tilgjengelig som et RESTful API 
(PostgREST) (PostgREST). Supabase håndterer også autentisering i applikasjonene ved 
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bruk av Json Web Token (Supabase). JWT er en åpen industristandard for å representere 
sikker håndtering av utvekslinger mellom to parter (M. Jones, 2015). 


Beiteweb 


Beitweb er en interaktiv SPA (single page application) med opptegning av dynamisk 
HTML på klientsiden (client side rendering). 


Beiteweb kjøres i et «dockerized» Node.js miljø via en Express.js webserver på Heroku, 
som er en PaaS (Platform as a Service) (Heroku; Heroku). Oppgaven til webserveren er å 
tilgjengeliggjøre Beiteweb applikasjonen på internett. 


4,8.2 Mobilapplikasjon / Beiteloggen 
Denne seksjonen beskriver valgene som ble gjort rundt utviklingen av beiteloggen og 
hvordan forskjellige elementer er blitt benyttet i applikasjonen. 


4.8.2.1 Valg av Språk / Rammeverk 


Native eller kryssplattform 


Ved starten av prosjektet var det nødvendig å gjøre noen valg angående hvilke språk 
systemet skulle kodes i. Målgruppen i prosjektet er en relativt bredt omfattende gruppe, 
som ikke må forholde seg til noen retningslinjer i forhold til hvilken telefontype de eier. 
Dette til forsjel fra for eksempel en bedrift som påkrever sine ansatte å benytte iPhone. 
På bakgrunn av dette startet teamet med å gjøre research på hvilke operativsystemer 
som er mest prevalent i markedet i dag, slik at systemet kunne nå flest mulig brukere. 


StatCounter Global Stats 
Mobile Operating System Market Share Worldwide from May 2021 - May 2022 


0 


OG Android 0 iOS O Samsung O KaiOS < Unknown Nokia Unknown O Windows + Series 40 — Other (dotted) 


Figur 4.90: Statistikk over mobiloperativsystemer i verden 2021-2022 (Statcounter, 
2022b) 


På verdensbasis er det en klar overvekt av Android mobiltelefoner med en markedsandel 
på litt over 70% mens Apple holder en andel på ca. 28%. Andre operativsystemer slik 
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som Samsung, KaiOs og Nokia holder markedsandeler på til sammen ca. 1 % 
(Statcounter, 2022b). Basert på disse tallene ser det fortsatt ut til at Android OS 
dominerer markedet nå. Brukergruppen for dette prosjektet holder derimot til i Norge og 
det kunne derfor være aktuelt å se på Norges fordeling for seg, da alle land vil ha en 
egen profil og vi vet at teknologimarkedet i Norge varierer fra for eksempel India eller 
Kina. 


StatCounter Global Stats 
Mobile Operating System Market Share Norway from May 2021 - May 2022 


0iOS Android O Samsung O Windows — Other (dotted) 


Figur 4.91: Fordeling av mobil OS i Norge 2021-2022 (Statcounter, 2022a) 


Ved å undersøke data fra det norske markedet presentert i grafen over, ser vi at iOS 
generelt holder en mye høyere markedsandel i Norge enn i verden på generell basis. I 
Norge sitter iOS på markedsandeler tilsvarende 59% mens Android her legger seg på 
rundt 40%. Andre operativsystemer utgjør litt under 1% av markedet (Statcounter, 
2022a). 


Basert på den presenterte undersøkelsen av markedsandeler ønsket teamet å tilby en 
løsning som støtter både iOS og Android operativsystemene likeverdig. Dette ville sikre 
at størst mulig del av systemets målgruppe nås og at flest mulig brukere kan benytte seg 
av systemet. Ettersom andelen av andre operativsystemer er så lav som under 1% både 
på Norgesbasis og i verden, vil mobilapplikasjonen i førsteomgang ikke være utviklet 
med tanke på disse brukerne. Teamet gikk derfor videre i prosessen med målet om å 
utvikle for iOS og Android plattformene. 


Med bakgrunn i denne konklusjonen utredet teamet hvilke teknologier som kunne være 
mest aktuelle for å dekke begge plattformer effektivt. Android og iOS tilbyr Java/Kotlin 
og Swift respektivt som utviklingsteknologier for utvikling av «native» (plattformekte) 
løsninger til deres plattformer (developers, Andoid; developers, Apple). Skulle man velge 
å benytte seg av en av disse ender man dermed opp med løsninger som kun kjøres på en 
av plattformene. Et alternativ ville eventuelt være å kode løsningen i begge språk slik at 
man ender opp med to native løsninger, en som kan kjøre på Android og en som kan 
kjøre på iOS. Dette er derimot svært tidkrevende og ettersom teamet kun bestod av to 
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utviklere ville dette være en nærmest umulig oppgave å gjennomføre gjennom den 
begrensede prosjektperioden. Teamet valgte derfor å gå bort fra tanken på utvikling av 
native løsninger og fokusere på teknologi som tillot utvikling av én kodebase for begge 
plattformer. 


Å utvikle en løsning for både Android og iOS plattformer som baserer seg på én enkelt 
kodebase kalles kryssplattformutvikling og har både fordeler og ulemper sammenliknet 
med native utvikling. Noen av fordelene og ulempene med kryssplattformutvikling vs 
native utvikling presenteres i tabellen under. 


Kryssplattformutvikling 


Fordeler Ulemper 
Når et større marked Dårligere ytelse 
En enkelt kodebase UX og UI avvik fra plattform standarder 
Raskere utviklingstid Færre API'er kan være tilgjengelige 
Raskere deployment Native apps kan skalere bedre 
Redusert arbeidsmengde 
Konsistent funksjonalitet over plattformer 


Tabell 4.10: Fordeler og ulemper ved kryssplattformutvikling sammenliknet med native 
utvikling (Marchuk) (Merixstudio, 2022) 


Som allerede er blitt diskutert i tidligere avsnitt har man muligheten til å nå et større 
marked ved bruk av kryssplattformutvikling da man utvikler for begge plattformer 
samtidig. I tillegg kan det være en fordel å kun ha en kodebase for utviklerne å forholde 
seg til når det kommer til utviklingstid og deployment. Utviklingstiden vil kortes ned 
ettersom utviklerne kun trenger å kode løsningen én gang, og selv om de fortsatt vil 
behøve å ta hensyn til OS spesifikk funksjonalitet, vil de kunne forholde seg til ett språk 
og de samme utviklerne vil kunne gjennomføre endringer for begge plattformer 
(Merixstudio, 2022). 


Et annet aspekt av fordelene med en felles kodebase er at ettersom den samme 
kodebasen blir deployert til produksjon for begge plattformer vil begge «versjoner» av 
applikasjonen ha samme funksjonalitet til enhver tid. Det vil dermed sjeldent være avvik 
mellom funksjonalitet man finner i Android og iOS versjonen eller forskjellige måter å 
utføre en handling på basert på hvilket OS man benytter seg av (Merixstudio, 2022). 


På den andre siden finnes det også ulemper med kryssplattformutvikling. Den største av 
disse, som ofte er en av de mest omdiskuterte ulempene, er applikasjonenes ytelse. På 
grunn av nødvendigheten for et ekstra abstraksjonslag som abstraherer bort de 
underliggende plattformspesifikke elementene, vil kryssplattformapplikasjoner ofte ha 
noe dårligere ytelse enn det native applikasjoner har. Dette er fordi native løsninger 
interagerer direkte med operativsystemet (Merixstudio, 2022) (Marchuk). I tillegg til 
dette kan det med kryssplattformutvikling være en utfordring å utforme og benytte seg 
av plattfformspesifikt design og standarder definert av operativsystemene. Det finnes 
forskjellige navigasjonsmønstre og oppførsel hos Android og iOS som utviklerne er nødt 
til å håndtere spesifikt i en kryssplattformapplikasjon, men som de ikke nødvendigvis 
behøver å tenke på ved native utvikling (Marchuk) (Merixstudio, 2022). 


Ved kryssplattformutvikling er det viktig å være obs på at ikke alle API'er som er 
tilgjengelige for hver nativ plattform er tilgjengelig gjennom kryssplattformspråkets 
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plattform. Dette vil si at enkelte funksjonaliteter som leveres til Android eller iOS kanskje 
ikke vil være tilgjengelige ved bruk av en kryssplattformspråk da dette vedlikeholdes og 
leveres av miljøet rundt eller utviklerne av språket (Marchuk). Til slutt er det relevant å 
diskutere at native løsninger kan skalere bedre enn det kryssplattformløsninger, 
avhengig av hvor mye systemressurser de benytter seg av og at en native løsning ofte 
har bedre ressursbruk på bakgrunn av det ekstra abstraksjonslaget i 
kryssplattformløsningene (Marchuk). 


For dette prosjektet vurderte teamet at fordelene ved kryssplattformutvikling klart 
utveide ulempene med tanke på tidsaspekt, håndterbarhet og å nå flest mulig i 
målgruppen. 


Hvilket kryssplattformspråk 


Det finnes mange kryssplattformalternativer der ute, men ettersom teamet var opptatt 
av å optimalisere ytelsen så godt som mulig, var ingen av kryssplattformløsningene som 
fungerer som wrappere for webapplikasjoner aktuelle. Dette kortet ned den aktuelle 
listen betydelig og teamet kom tidlig frem til at valget stod mellom tre rammeverk hvor 
alle kompileres og kjøres på mobilenheten. De tre alternativene var React Native, Flutter 
og Xamarin. 


React Native 


React Native er et rammeverk som er utviklet og vedlikeholdt av Meta. Det baserer seg 
på JavaScript og React som er et bibliotek for utvikling av brukergrensesnitt 
(ReactNative). Selv om React Native skrives i JavaScript så rendres komponentene til 
native plattform komponenter. Dette bidrar til at man får native følelse i en 
kryssplattform app og man kan benytte seg av mange av de samme API'ene som native 
apper gjør (ReactNative). 


Flutter 


Flutter er et rammeverk som utvikles og vedlikeholdes av Google. Flutter skrives i Dart 
som er Googles eget objektorienterte programmeringsspråk. Flutterkode kompileres til 
maskinkode for mobilapplikasjoner og JavaScript for webløsninger for rask og god 
opplevelse på linje med native applikasjoner (Flutter). 


Xamarin 


Xamarin er en ekstensjon av Microsofts .NET plattform med verktøy og biblioteker 
designet for utvikling av mobil-, utstyrs- og Windowsapplikasjoner. Xamarinkode 
kompileres for native ytelse og gir utviklerne tilgang til plattformens underliggende APT'er 
(Microsoft). 


For å bedre illustrere og sammenlikne de ulike alternativene utarbeidet utviklerne en 
matrise. 
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Dokumentasjon og API 
tilgang 


Rammeverk Kryssplattform | Kartstøtte 


Android 
(Java/Kotlin) 


Tabell 4.11: Matrise for valg av applikasjonsrammeverk 


Det viste seg tidlig at alle de aktuelle løsningene tilbød den funksjonaliteten som var 
nødvendig for utvikling i prosjektet. Basert på dette ble det til slutt lagt stor vekt på hva 
utviklerne i teamet kunne fra før og hva de var interessert i å lære mer om. Ingen av 
utviklerne var kjent med .NET plattformen fra før. I tillegg til dette bygges Xamarin 
applikasjoner sammen med flere av de inkluderte bibliotekene som benyttes i prosjektet 
og dermed har applikasjonene en tendens til å måtte optimaliseres ytterligere enn andre 
alternativer (Altexsoft, 2020). Med bakgrunn i dette valgte teamet bort dette 
alternativet. 


Teamet hadde dermed valget mellom React Native og Flutter. Begge utviklerne i teamet 
hadde erfaring med Flutter, men kun erfaring med React gjennom webutvikling. Med 
bakgrunn i at begge var interessert i å lære mer om Flutterutvikling og forbedre sine 
kunnskaper og evner på dette området falt valget til slutt på Flutter. 


Flutter støtter per i dag Android API versjoner tilbake til versjon 19 (Flutter). Dette 
dekker kravet fastsatt i den tekniske kravspesifikasjonen om at Android versjoner tilbake 
til Queen Cake skal støttes da Queen Cake i dag kjører API versjon 29 (developers, 
Andrioid). I tillegg støtter Flutter versjoner av iOS tilbake til iOS 9, noe som også dekker 
det fastsatte kravet om dekning av iOS versjoner tilbake til versjon 12, som er det siste 
som vedlikeholdes av Apple sikkerhetsmessig (Flutter) (Apple). Utover dette forsikret 
teamet seg om at de øvrige tekniske spesifikasjonene fastsatt i den tekniske 
kravspesifikasjonen ble dekket av de API'ene og funksjonaliteten Flutter tilbyr per i dag. 
For en full oversikt over den tekniske kravspesifikasjonen se vedlegg B. 


4.8.2.2 Utvikling: Flutter og Dart 

Flutter som er Googles UI bibliotek for kryssplattformutvikling, fungerer som et 
rammeverk for UI komponenter som kalles widgets. Widgets kommer ferdig definert fra 
Flutter som de ville gjort i andre UI-bibliotek, eller de kan lages av utviklerne selv. 
Logikken som skrives i og rundt widgets for å oppnå ønsket funksjonalitet skrives i Dart, 
Googles eget objektorienterte programmeringsspråk. Dart ble ikke opprinnelig utviklet 
for Flutter, men er blitt en av de viktigste byggesteinene i deres kryssplattformlandskap 
(Flutter). 


93 


Erfaring 


En widget fungerer i praksis som en liten del av en applikasjon som settes sammen med 
andre widgets for til sammen å utgjøre en fullstendig løsning. På bakgrunn av denne 
modulære strukturen er det gunstig og god praksis å utarbeide så generiske widgets som 
mulig slik at de kan gjenbrukes flere steder i applikasjonen. På denne måten kan man 
benytte seg av koden flere ganger og det er ikke nødvendig å produsere noe nytt hver 
gang man har behov for en komponent. 


Gjennom prosjektet har utviklerne både benyttet eksisterende widgets og bygget deres 
egne. Et eksempel på dette er knappene på profilsiden i applikasjonen hvor teamet har 
definert sitt eget format på interaksjonselementene da dette ikke er noe som tilbys 
direkte fra Flutters bibliotek. Her er en ListTile omgitt av en «Material komponent» som 
er tillagt egne designelementer slik som elevasjon og border radius. Inni ListTile'en finner 
man igjen to ikon widgets og en Text widget. Man kan finne igjen dette mønsteret for alle 
interaksjonselementer i applikasjonen. 


I Tr 
E Hanne Hove 


Innstillinger 


Last opp ny tur 


Mine invitasjoner 


Logg ut 


Figur 4.92: Illustrasjon av egetutviklet widgetelement 


Dart er Googles egne objektorienterte programmeringsspråk og benyttes sammen med 
Flutter for å skrive logikk for Widgetfunksjonalitet. Dart og Flutter er tett sammenkoblet, 
og det kan være noe vanskelig å skille hva som er «Backend» og hva som er «Frontend» 
rent strukturmessig. Det er derimot en del logikkfunksjonalitet som er klart adskilt fra 
Widgettrærne, slik som datamodeller, datainnhenting og lagringsfunksjonalitet. 


Statehåndtering 


For statehåndtering i applikasjoner benytter Flutter seg av noe som kalles providers. 
Providers legges «rundt» aktuelle widgets for å «provide» dem med en egen «state» som 
kan aksesseres av alle widgets i widgettreet under widgeten som er direkte barn av 
Provideren. Når denne øverste Widgeten fjernes fra den «aktive stacken» i applikasjonen 
(Det vil si at man navigerer vekk fra widgeten) vil widgeten «unmountes» som også vil 
«Dispose» den aktuelle provideren. Når dette skjer, vil providerens state fjernes og man 
vil starte på nytt med en frisk provider neste gang den aktuelle komponenten «mountes» 
på nytt (Ved for eksempel å navigere til den). Et eksempel på dette i dette prosjektet er 
«Registrer Flokk provideren» som instansieres hver gang en flokk skal registreres på en 
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tur, og som deretter «dismountes» og startes på nytt for neste flokk. På denne måten 
garanterer man at brukeren alltid starter med en «ren» state. 


Man kan også ha globale providers i applikasjonen som holder på global state. Et 
eksempel på dette i dette prosjektet er «Profil provideren» som holder styr på hvilken 
bruker som er logget inn i hele applikasjonen og gjør at man dermed har tilgang til 
brukerinfo gjennom hele applikasjonsflyten. Dette er nyttig både på profilsiden og for å 
hente den relevante dataen for brukeren på Beitegruppe og Aktivitetsskjermen. 


Lokal lagring 


Når en tur gjennomføres i mobilapplikasjonen er det muligheter for at brukeren befinner 
seg utenfor dekningsområdet for mobilnettet. For at brukeren trygt skal kunne 
gjennomføre en tur uten å risikere tap av nettverk og dermed data er det blitt 
implementert en løsning som lagrer turen lokalt frem til brukeren får tilbake nettet og 
kan laste turen trygt opp til databasen. I løpet av selve turen lagres turdetaljene i flere 
state providere i applikasjonen. De holder på all data om turen og oppdateres 
kontinuerlig i løpet av gjennomføringen. Når turen avsluttes skrives dataen til det lokale 
fillagringssystemet for bevaring frem til brukeren ønsker å laste opp dataen til skyen. Når 
brukeren laster opp dataen suksessfullt, slettes den lokale kopien i fillagringssystemet. 
For at dette skal kunne gjennomføres serialiseres all data mellom json format og 
dataobjekter ved lesing og skriving av fil. Dette er det skrevet egne metoder og 
funksjoner for. I tillegg er det skrevet utfyllende tester for å sikre at funksjonalitet 
fungerer som tiltenkt. Dette er det skrevet mer om i «Testing». 


4.8.3 Webapplikasjon / Beiteweb 
Denne seksjonen beskriver valgene som ble gjort rundt utviklingen av Beiteweb og 
hvordan forskjellige elementer er blitt benyttet i applikasjonen. 


4.8.3.1 Valg av Språk / Rammeverk 

Ved valg av språk og rammeverk for webapplikasjonen ble det tungt vektlagt hvilken 
erfaring utviklerne i teamet satt på fra før, i tillegg til trendene i dagens marked. Begge 
utviklerne i teamet er mest komfortable med JavaScript som utviklingsspråk når det 
kommer til webutvikling. Det ble derfor bestemt at rammeverket de ville benytte seg av 
burde være et JavaScript-rammeverk, noe som eliminerte løsninger som for eksempel 
Django for Python og liknende. Når det kommer til rammeverk som benytter JavaScript 
som utviklingsspråk er det tre stykker som er mest brukt. Disse tre er React, Vue og 
Angular. 


Grafen under viser antall nedlastinger av hvert rammeverk gjennom det siste året via 
Node package manager, et pakkeadministreringsverktøy. 
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npm trends 


angular vs react vs vue 


Downloads in past 1 Year v 


Figur 4.93: Statistikk over de mest nedlastede rammeverkene for webutvikling hos Node 
package manager (NPM, 2022) 


Begge utviklerne i teamet hadde erfaring med både React og Vue som 
utviklingsrammeverk, men etter å ha evaluert grafen over bestemte teamet seg for å ta 
utgangspunkt i React. Dette både fordi begge hadde erfaring med dette rammeverket 
med også fordi det er et godt støttet rammeverk som for tiden virkelig skiller seg uti 
form av popularitet blant utviklere (NPM, 2022). 


4.8.3.2 Frontend: React — Typescript 

Frontend ble løsningen utviklet med React, TypeScript og Redux. Typescript ble valgt til 
fordel for JavaScript ettersom det gir muligheter for å gi typer til elementer og objekter 
slik at det er enklere å oppdage feil underveis i utviklingen (Typescript). 


For statehåndtering ble Redux benyttet sammen med Redux toolkit. Redux gir 
applikasjoner muligheten til å håndtere en global state for applikasjonen slik at flere 
komponenter som er adskilt fra hverandre kodemessig alle har tilgang til den samme 
tilstandsavhengige dataen og kan tegnes på nytt på skjermen basert på en «single 
source of truth» (Redux). I tillegg ble RTK (Redux toolkit) benyttet for å forenkle 
oppsettet av Redux store (Organiseringen av data i Redux containeren som holder på 
global data), og å effektivisere datainnhenting fra API'er. Ved hjelp av RTK Query hentes 
data direkte fra APT'er og settes direkte i Redux store klar for bruk i komponentene i hele 
applikasjonen i stedet for at en komponent har ansvar for innhenting av data som 
deretter settes i Redux store. Dette bidrar til å effektivisere datainnhentingen både ved å 
hente inn data ved innlasting uten å være avhengig av en enkelt komponent i tillegg til at 
dataen caches, slik at data ikke oppdateres unødvendig om ingenting har endret seg i 
innholdet siden forrige innlasting (ReduxToolkit). 
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Et eksempel på bruk av Redux og RTK Query i webapplikasjonen er på dashbordet hvor 
data hentes inn gjennom APT'er fra Supabase når en bruker aksesserer siden. Responsen 
fra API'et transformeres via RTK Query til et annet format for å gjøre det enklere å finne 
turer gjennomført per beitegruppe og settes i Redux store. Når en bruker velger hvilken 
beitegruppe han/hun ønsker å se data for settes den valgte beitegruppen i Redux store 
og all data kan enkelt hentes fra RTK Query via egne hooks. Når en bruker klikker på en 
tur for å se mer data om den, ligger denne informasjonen allerede tilgjengelig i Redux 
store og siden tilgjengeliggjøres umiddelbart uten videre innlastningstid. Når brukeren 
navigerer tilbake til dashbordet vil den tidligere valgte beitegruppen fortsatt være valgt 
ettersom den ble satt i Redux store tidligere. Slik kan state bevares mellom 
sidenavigering og gi brukeren en mer helhetlig opplevelse uten følelsen av å måtte 
«begynne på nytt» hver gang han/hun kommer til dashbordet. 


4.8.3.3 Backend 

For å tilby data og autentisering til webapplikasjonen og deretter å «serve» 
webapplikasjonen på nettet benyttes det det to backend løsninger. Hovedløsningen for 
data og autentisering ligger hos Supabase som vist i «Systemarktitektur» og dette er 
diskutert videre i seksjonen «Database». 


For å «hoste» webapplikasjonen er det blitt utviklet en webserver som er hostes på 
Heroku. Webserveren er utviklet med Node.js, Javascript og Express.js hvor alle treff på 
www.beiteweb.heroukapp.com returnerer webapplikasjonen. Express-serveren er satt 
opp med middleware levert av Helmet.js som er med på å sikre løsningen mot 
forskjellige sikkerhetsangrep som Cross-Site Request Forgery og Cross-Site Scripting. 
Teamet har valgt denne løsningen for levering av webapplikasjonen på grunn av at 
Heroku som en PaasS (Platform as a service) har et brukervennlig grensesnitt for oppsett 
av forskjellige hosting tjenester. I tillegg tilbyr de en enkel integrasjon mot 
kildekodebasen på Github, som er med på å bidra til at den oppsatte CI/CD (Continous 
Integration and deployment) konfigurasjonen fungerer godt, og kontinuerlig sikrer at den 
siste versjonen av kodebasen er tilgjengelig på Heroku. Mer om CI/CD er dokumentert i 
«Continuous integration and deployment». 


4.8.4 Database: Supabase (BaaS) 

Mobilapplikasjonen og Webapplikasjonen deler en felles database hvor all informasjon 
som lagres i systemet er organisert. Supabase ble originalt utviklet som et alternativ til 
Firebase som er Googles «Backend as a service» plattform (Supabase). Hovedforskjellen 
mellom Firebase og Supabase databasemessig er at Firebase tilbyr en NoSQL løsning 
som vil si at databasestrukturen ikke er organisert med tabeller slik tradisjonelle 
databaser er, men heller i samlinger og dokumentstrukturer, mens Supabase baserer seg 
på Postgress struktur som er bygget opp med databasetabeller på tradisjonelt vis 
(Firebase) (Supabase). Ettersom teamet har erfaring med arbeid med SQL databaser og 
identifiserte at den dataen som skulle lagres gjennom prosjektet i høyeste grad hadde 
klare relasjoner til hverandre, vurderte de det som naturlig å benytte seg av et SQL 
basert databasealternativ. I tillegg ønsket teamet å benytte seg av en «Backend as a 
service» løsning da dette gjør det enklere å sikre dataoverføring, forenkler og sikrer login 
og autentiseringsprosesser og reduserer risikoen for serversvakheter (CloudFlare). 
Supabase var derfor et naturlig valg som tilbød den funksjonaliteten teamet ønsket seg. 


«Backend as a service» eller BaaS beskriver løsninger hvor leverandøren leverer 
programvaretjenester som tradisjonelt sett skjer på en server til utviklere gjennom 
APT'er, slik som bruker autentisering, database administrasjon, skylagring og hosting 
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(CloudFlare). For både webapplikasjonen og mobilapplikasjonen ble Supabase benyttet 
for å håndtere innlogging og autentisering av brukere, sikker lagring av brukerdata og 
sikker lagring av brukerregistrert data. 


Ettersom Supabase bruker Postgress internt for organisering av data og å gjøre 
spørringer lar databasen brukere sette opp egne tabeller og knytte dem sammen 
gjennom fremmednøkler slik som i en tradisjonell SQL database. Figuren under viser det 
utarbeidede databasediagrammet for systemet. 
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Figur 4.94: UML diagram for systemet 


Basert på det utarbeidede diagrammet som viser sammenhengen mellom de forskjellige 
tabellene og entitetene i databasen ble tabellene opprettet i Supabase. Figuren under 
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viser et utdrag fra Beitegruppetabellen med flere entiteter i tillegg til en oversikt over de 
forskjellige tabellene i databasen. 


created at : tamptz name text 


public 


New table 04b064c1-5496-4c5d-96e6-3003508f8ab3 2022-03-13 23:06:59.792803+00 Hedmarksgjengen 


06ab96f8-6baf-4e0e-9c2e-9f1021d0bcd83 2022-03-13 23:12:54.049448+00 Østfold gjengen 
d711d633-bfb7-47de-b79e-1dbf8f313d6d 2022-05-28 14:05:41.585651+00 Oppdalsgruppa 
event 
farm 
flock 
grazingGroup 


mage 


location 
member 
profiles 
sheep 
trip 


waypoint 


Figur 4.95: Oversikt over tabellene i Supabase database 


Basert på de tabellene og dermed datamodellene som er definert vil Supabase generere 
endepunkter for henting, innsetting og oppdatering av data som kan benyttes både i Dart 
og i JavaScript. Slik interagerer begge appene sømløst med databasen og man vil se 
endringer reflektert i den ene om man oppdaterer databasen fra den andre. 


For entiteter som ikke har primitive datatyper, slik som mediafiler, benytter Supabase 
seg av «Storage buckets» for lagring. Dette innebærer at det må defineres et eget 
filhierarki programmatisk når applikasjonene ønsker å lagre bildene for at de skal finnes 
igjen på en logisk måte. I dette systemet valgte teamet å opprette en egen «Storage 
bucket» kalt «Trips» deretter blir undermapper opprettet for hver tur basert på turens 
unike ID. I denne mappen finnes det igjen flere mapper basert på hvilken hendelse eller 
flokk bildene tilhører. Mappene får navn basert på hendelse eller flokk ID'en. Bildet under 
illustrerer oppsettet av slike mapper i «Storage buckets». 
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[3 43218600-0321-455c-Obfd 


[8 43218600-0321-4550-9bfd. 


Figur 4.96: Oversikt over en «Storage bucket» for en hendelse på en tur 


Basert på hvem som eier bildet eller hvem som er administratorer og medlemmer i 
beitegruppene er det satt opp egne regler for hvem som kan lese eller slette bilder fra 
databasen. 


Når en bruker ønsker å opprette en profil i en av applikasjonene opprettes det en entitet i 
«Authentication» tabellen i Supabase som er en Supabase-generert tabell som holder på 
epost, opprettelsestidspunkt, siste innloggingstidspunkt og brukerId. Samtidig opprettes 
det en entitet med same Id og Epost i tabellen «profiles» som holder på dette i tillegg til 
annen data brukeren kan endre selv slik som fornavn, etternavn og profilbilde URL. Når 
brukeren først får tilsendt verifikasjonslenken ved opprettelse av en profil vil brukeren 
være flagget i databasen som «ikke verifisert» og ingen brukerdata utenom epost vil 
være satt i «profiles» tabellen. Når brukeren klikker på innloggingslenken de fikk tilsendt 
vil systemet oppfatte at brukeren er flagget og be brukeren fylle inn ytterligere detaljer 
for å fullføre sin profil med de detaljene han/hun ønsker i tillegg til ønsket passord. Når 
dette er gjennomført fjernes verifikasjonsflagget fra brukeren og kontoen er klar til bruk. 


4.8.5 Eksterne APIer og biblioteker 

I både mobil- og webapplikasjonen er det blitt brukt flere forskjellige biblioteker og API'er 
for å løse kravene til applikasjonene. I dette avsnittet trekkes noen av dem som er 
ansett som viktigst for oppfyllelse av løsningens krav frem. 


4.8.5.1 Mobilapplikasjon 

En av de mest essensielle funksjonene i mobilapplikasjonen er kartet som brukes når 
brukeren er på tur. Kravene til kartet inkluderer flere interaktive og tilpassede løsninger 
som registrering av dyr og hendelser, og nedlastning. På grunn av dette har det vært 
viktig å bruke et bibliotek som har tillatt egne implementasjoner utover bare å vise et 
kart til bruker med posisjon. Biblioteket Flutter Map har et godt og fleksibelt API å jobbe 
med og har tillatt å legge til alle funksjonaliteter det har vært behov for. Dette er 
funksjonalitet som forskjellige kartkilder, kartprojeksjon, kartlag, bevegelsesgjenkjenning 
og posisjonsdata (Fleaflet.dev, 2022). Det ble tidlig klart gjennom samtaler med 
domeneeksperten at han vurderte Kartverket som det beste alternativet som kartkilde, 
da de sitter på utfyllende informasjon og tilbyr gode detaljerte kartlag over det meste av 
Norge. Derfor er dette blitt valgt ved implementasjon i applikasjonen. 
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Et av de andre viktige kravene som ble stilt av domeneeksperten var opplesning av 
registreringsalternativer i «kikkertmodus». For å løse dette er det blitt implementert 
stemmeopplesning av presentert tekst og handling fra bruker. For denne funksjonaliteten 
ble det vektlagt å bruke et bibliotek som støtter norsk og som har et enkelt grensesnitt å 
jobbe med. Teamet fant Flutter TTS til å være en god løsning (tundralabs.com). 


4.8.5.2 Webapplikasjon 

Kartet som vises i webapplikasjonen er hentet inn ved bruk av APT'er levert av Leaflet. 
Leaflet er et av de mest populære JavaScript bibliotekene for kartløsninger per i dag og 
har muligheter for egendefinerte markører, opptegning av lagrede koordinater og 
innhenting av ulike eksterne kart-lag (Leaflet). Kartkilden som benyttes i kartet er hentet 
fra Kartverket da dette var den valgte kartkilden for mobilapplikasjonen og det er 
naturlig å benytte en løsning brukeren kjenner igjen i webapplikasjonen. I kartet som 
vises over en tur tegnes turen inn i kartet ved hjelp av en liste av koordinater lagret i 
databasen som oversettes til «Polylines». Markørene for registreringsposisjoner og 
registrerte hendelser er hentet fra internett mens markøren for registrerte flokker er 
egenprodusert i Figma. 


For å vise beitedata i kartet er WMS tjenester (Web Map Service) fra NIBIO blitt benyttet. 
Vegetasjonskartene NIBIO leverer inneholder data om flere vegetasjonstyper og lar 
brukere benytte seg av ett eller flere av kartlagene i egne kartløsninger (NIBIO). 
Beitekartet fra NIBIO er gratis og fri til bruk i egne løsninger så lenge man opplyser om 
at dataene kommer fra NIBIO. Figuren under viser NIBIOs kartlag for sauebeite lagt inn i 
Leaflets kartløsning med kredditering av Leaflet og NIBIO nede i høyre hjørne. 


Må Vis beitekvalitet i kart Tegnforklari 
Registreringsposisjon Hendelsesposisjon —Flokkposisjon 0 9 ng 
EP 


7 Tegnforklaring beiteoversikt 


eo Dyrka mark 


% 

S&& Mindre godt beite 
j OG Godtbeite 

8 


Svært godt beite 


"Tsotøvrielier 2 å Å mfl N IN Leaftet | & Kartverket, 6 NIBIO 


Figur 4.97: Beitelag vist i kartet i webløsningen 


For å gi webapplikasjonene et helhetlig og gjennomgående design har 
komponentbiblioteket Chakra UI blitt tatt i bruk. Chakra fokuserer på å tilby tilgjengelige 
og modulære komponenter for React-utvikling og har vært med på å forenkle 
utviklingsprosessen ved å tilby komponenter som enkelt kan modifiseres ved behov 
(Chakra). Gjennom Chakra har det blitt satt opp et eget tema for applikasjonen hvor 
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Beitevollar og hagemarkskog 


farger, temaer, komponentstiler og så videre, enkelt kan byttes ut ved behov. Flere av 
chakrakomponentene er blitt modifisert eller bygget på for å møte applikasjonens behov. 


4.8.6 Tekniske implementasjoner 
Denne seksjonen beskriver spesielt nevneverdige implementasjoner i applikasjonene og 
som er kritiske for systemets operasjon og leveranse av tjenester. 


4.8.6.1 Nedlasting av kart 

Et viktig krav for systemet var at kartutsnittet som brukes for en oppsynstur er 
tilgjengelig hele tiden, under hele turen. Ettersom brukere er i fare for å miste 
mobildekning på oppsynsturer og derfor også tilgangen til oppdaterte kartutsnitt, er det 
utviklet en løsning for å laste ned kartutsnittet for området før turen skal gjennomføres. 
Dette gjøres ved at alle kartfliser i området innenfor kartvinduet på «start tur» skjermen, 
blir lastet ned og lagret lokalt på telefonen før turen blir startet. Når turen startes hentes 
det inn kartutsnitt med «online-first» strategi med tilbakefall til cache, noe som vil si at 
så lenge telefonen har mobildekning vil den bruke internett til å laste inn kartfliser og når 
telefonen mister internett hentes kartets fliser fra en nedlastet versjon på telefonen. 


For å få til denne implementasjonen, har det blitt bruk Flutter bibliotekene Flutter Map 
(Fleaflet.dev, 2022) og Flutter Map Tile Caching (jaffaketchup.dev, 2022). Flutter Map er 
utviklet med utgangspunkt i Leaflet, som er den samme kartløsningen brukt i 
webapplikasjonen, noe som gjør bruken av kart relativt lik i begge løsninger og dermed 
mer intuitiv (Fleaflet.dev, 2022). 


4.8.6.2 Designmønstre 

Med perspektiv på kode og kodekvalitet har teamet vært opptatt av å bruke 
konvensjonelle design mønstre for å løse forskjellige problemer og oppgaver. Dette har 
teamet sett på som viktig for å følge DRY (Do Not Repeat Yourself) og for å minimere 
bugs og forenkle enhetstester (Andrew Hunt, 1999). For eksempel brukes det singleton 
patterns for å aksessere Supabase database klient instansen i mobilapplikasjonen. Dette 
gjøres for å sikre at det ikke finnes flere database tilkoblinger omkring i applikasjonen 
samtidig, som igjen sikrer at løsningen er trådsikker (Thread Safe). 


Teamet har også benyttet seg av «builder patterns» flere steder i mobilapplikasjonen da 
dette har en god implementasjon i Dart gjennom et språkverktøy som kalles «Cascade» 
(Dart). Det vil si i stedet for å ha funksjoner som returnerer «This» keywordet som typisk 
gjøres i Java, kan man i Dart heller bruke en «..» notasjon for hvert metode-kall. 


4.8.6.3 Posisjondata 

For å få tilgang til posisjonsdata i mobilapplikasjonen brukes det et geolokasjonsbibliotek 
som bruker de underliggende integrerte lokasjonstilbyderne på Android og iOS 
(baseflow.com). Her brukes sensordataene i telefonen for å finne posisjon og bevegelse 
gjennom akselero- og magnetometer. Posisjonsdata blir oppdatert fortløpende, men for å 
begrense datamengden som lagres, lagres kun punkter hvor endring i posisjon utgjør 
mer enn ti meter eller ved et tidsintervall på to minutter. Dette er parametere som har 
blitt etterspurt og foreslått av professor Hvasshovd. 


Et viktig implementasjonspunkt for posisjonsdata er at denne tjenesten oppdaterer og 

lagrer data forløpende selv om telefonen er i låst modus. Dette vil si at når skjermen er 
skrudd av, eller hjem skjermen ikke er tilgjengelig, eller om man går ut av appen mens 
en tur pågår, for eksempel ved å åpne en annen app eller bevege seg til hjem-skjermen 
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vil data fortsatt registreres. Dette er viktig for at turen blir registrert riktig og at brukeren 
kan bruke telefonen til andre ting under en aktiv tur. 


4.8.7 Continuous integration and deployment 

I prosjektet har det vært brukt CI/CD (Continous integration and deployment) for både 
web- og mobilapplikasjonen. Dette innebærer at kode som tilføres prosjektet blir 
automatisk testet og bygget før det integreres i kodebasen og at når testene og bygget 
er gjennomført uten feil så sendes koden ut til produksjon. 


For å sørge for at Flutter applikasjonen fungerer etter nye implementasjoner så kjøres 
det en Flutter CI aksjon på hver pull request til repositoriet. Denne aksjonen bygger og 
kjører alle testene i kodebasen for å oppdage om koden ikke kan bygges, eller om noe 
ikke lenger samsvarer med testene som er skrevet. Dette verktøyet er med på å sørge 
for at kodebasen alltid er i en fungerende tilstand etter nye tillegg. Under følger et utsnitt 
av den oppsatte integrasjonen som sørger for at testene kjøres. 


H flutter.yml 
name: Flutter Test 
on: 
push: 
branches: [main] 
pull request: 
branches: [main] 
jobs: 
test: 
runs-on: ubuntu-latest 
steps: 
- uses: actions/checkoutav3 
- name: Flutter action 
uses: subosito/flutter-actionav2 
- run: flutter pub get 
- run: flutter test 


For webapplikasjonen er det satt opp en aksjon som sørger for at alle nye kodetillegg 
som passerer automatiske tester og bygg sendes ut til produksjon. Dette gjør at 
Beiteweb, som er tilgjenglig åpent under Herokus domene, vil være oppdatert med de 
nyeste endringene til enhver tid. 


4.9 Sikkerhet 


Ettersom den utviklede applikasjonen samler brukerdata og lagrer data spesifikt for 
brukere er sikkerhet et viktig aspekt. Gjennom prosjektet har det vært fokus på 
sikkerhet gjennom hele utviklings og planleggingsperioden. 


4.9.1 GDPR 


GDPR (General Data Protection Regulation) er en vedtatt regulativ innført for alle land 
med EU medlemskap eller som følger EU's standarder, som har vært i effekt siden 25 Mai 
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2018 (Consulting). Lov om etterfølgelse av EU regulativet i Norge ble vedtatt 15 juni 
2018 (Regjeringen, 2019). Loven sier at innsamling av personvernopplysninger skal 
foregå etter nødvendighet eller etter samtykke fra brukeren. I tillegg skal brukeren 
kunne få dataen sin slettet etter eget ønske ved både å kunne slette sin profil, men også 
ved å kontakte bedriften/innsamleren og få sine registrerte data fjernet fra deres 
systemer (Regjeringen, 2019). 


For å imøtekomme disse kravene er alle brukere som ønsker å benytte seg av systemet 
nødt til å godkjenne brukervilkår før de får opprettet en profil. Når innsamlingen av 
personlig data baseres på brukerens samtykke, har brukeren ifølge loven alltid mulighet 
å trekke dette samtykket tilbake. I tillegg kreves det at brukeren er over 13 år for å 
kunne gi et slikt samtykke til innsamling av data. Det finnes også en rekke andre faktorer 
brukeren skal informeres om før de samtykker til datainnsamling, som er spesifisert i 
personopplysningsloven (beredskapsdepartementet, 2018). I figuren under vises de 
utarbeidede brukervillkårene som må godkjennes. 


Personvernerklæring 


Personopplysninger vi samler inn 
og behandler 

Grunnleggende informasjon 

Navn. 


Kontaktinformasjon 

E-postadresse. 

Brukeraktivitet 

Oppsynsturer, beitelag, gårder og 
posisjon. 

Brukerhistorikk 

Historikk av oppsynsturer, beitelag og 
posisjon. 

Cookies 

Informasjonskapsler blir brukt for å 
håndtere innlogging, kryptert passord og Hove 

for brukerdefinerte innstillinger i 

applikasjonene. Informasjonskapslene 

har en standard levetid på 60 minutter, 

men utvides ved kontinuerlig bruk av 0 Oppdaterprofl 


tjenestene. 


Hanne 


Etternavn 


Hvordan vi bruker 

personopplysningene 

Grunnlag for databehandling Password 
Data vil bli behandlet basert på samtykke 

fra bruker av applikasjonen. Din 


informasjon vil bli samlet inn, organisert, 
lagret og brukt i applikasjonen i 


Slett profil 


Figur 4.98: Brukervilkår og mulighet for sletting av profil 


Brukerdataene som lagres i denne applikasjonen inkluderer epost, fornavn, etternavn, 
profilbilde og passord. Fornavn, etternavn og profilbilde er valgfritt og ikke påkrevd av 
brukeren å registrere. Epost og passord er begge nødvendige for opprettelse av profil. I 
tillegg til informasjonen som er direkte identifiserende for brukeren, lagres gjennomførte 
oppsynsturer brukeren har gjennomført og deres medlemskap i forskjellige grupper. 
Ettersom applikasjonen baserer seg på brukerens samtykke for innhenting og lagring av 
informasjon er det lagt til rette for at brukeren kan trekke sitt samtykke selv ved å ha 
muligheten til å slette sin profil. 
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4.9.2 Informasjonssikkerhet 

Gjennom utviklingen av applikasjonen er det blitt holdt et overordnet fokus på sikkerhet 
og applikasjonene er utviklet med hensyn på OWASPs topp 10 liste over 
sikkerhetsrisikoer (OWASP, 2021). Ikke alle risikoene vil bli diskutert i denne seksjonen. 


Brukeres tilganger til databasen 


Ettersom Supabase underliggende benytter seg av Postgres, finnes det også 
funksjonalitet for RLS (Row level security). RLS gjør det mulig å bestemme hvem som 
har tilgang til å se, editere og slette rader i en database (Microsoft, 2021). Dette 
innebærer at det er nedsatt regler i databasen for å sikre at kun brukere som er 
autorisert til å se informasjonen får tilgang til å hente ut den aktuelle informasjonen. 
Reglene er nedsatt i databasen via opprettelse av «Policies» som for eksempel kun lar 
brukere som er del av en beitegruppe få tilgang til å hente turene som er registrert i 
gruppen. 


XSS og SQL injeksjoner 


SQL (Structured Query Language) injeksjoner er en måte å ødelegge eller få tilgang til 
data i en database på gjennom å skrive SQL spørringer inn i input felter i applikasjonen 
som deretter vil utføres i databasen og returnere data som ikke skal være tilgjengelig for 
brukeren (W3Schools). Dette kan også resultere i endring av data eller sletting av 
databasen, noe som vil være katastrofalt for løsningen. Supabase benytter seg av en 
Postgres database som benytter SQL som spørrespråk og det er derfor av interesse å 
undersøke hvor godt den er beskyttet mot dette. I systemet er alle interaksjoner med 
databasen gjort gjennom Supabases api'er som parameteriserer alle spørringer som blir 
gjennomført. Dette betyr at brukernes input aldri blir sendt direkte til databasen i den 
formen de ble skrevet på, noe som også hindrer SQL injeksjoner i å utføres (Chavez, 
2021). 


XSS (Cross site scripting) angrep er også en form for injeksjonsangrep hvor en angriper 
skriver kode inn i inputfelt som senere bli lagret i databasen. Når informasjonen så 
hentes ut fra databasen på et senere tidspunkt vil koden blir utført på nettiden hvor 
informasjonen hentet fra databasen skulle vises (KirstenS). Ettersom ingen data i 
webapplikasjonen er dynamisk generert hvor HTML elementer må rendres inn fra 
innhentet data, sikrer React automatisk at all data som vises fra databasen konverteres 
til String format. På denne måten utføres ikke eventuelle skript som kan ha blitt lagret i 
databasen (StackHawk, 2021). 


4.10 Testing 


Gjennom og ved slutten av prosjektet ble det skrevet og kjørt flere tekniske tester som 
var med på å verifisere funksjonalitet både kodemessig og overordnet. I koden ble det 
utarbeidet enhetstester for å teste datamodeller, mapping av objekter og businesslogikk. 
Ved prosjektets slutt ble det gjennomført en systemtest for å evaluere hvor godt 
systemet imøtekom de kravene som hadde blitt utarbeidet før utviklingsstart. 
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En av hovedgrunnene til at tester har hatt en sentral rolle gjennom utviklingsprosessen 
er at prosjektet har brukt en BaaS. For å sikre at denne kunne kobles på uten 
medfølgende problemer var det viktig å verifisere funksjonaliteten til business logikk og 
datamodeller. Denne testskrivningsprosessen har medført at enkelte funksjonaliteter har 
blitt utviklet gjennom test-drevet utvikling som innebærer at alle tester ble skrevet før 
implementasjon av funksjonalitet. Dette har vært med på å bidra til at tilkobling til BaaS 
har vært veldig smidig. I tillegg er brukerinput et viktig og sentralt element i 
applikasjonen som medfører at det har vært viktig å sørge for at løsningene leverer utfall 
som samsvarer med de tilsiktede hensiktene til funksjonalitetene. 


4,10.1 Enhetstesting 

Det er skrevet både Black-Box og White-Box enhetstester for flere deler av systemet. 
Black-Box testene tester funksjonaliteten gjennom grensesnittet uten å vite noe om den 
underliggende kodede funksjonaliteten. Målet er å teste hvordan typiske ekstreme eller 
sjeldne situasjoner håndteres, et typisk eksempel er en funksjon som tar inn to integers 
og denne testes med å sende inn INT MAX og INT MIN, og så evaluere hvordan koden 
håndterer dette. De aller fleste testene er derimot skrevet i White-Box forstand hvor 
hensikten er å teste funksjonalitet med underliggende kjennskap til hvordan koden er 
implementert med mål om å teste de forskjellige utfallene koden kan ha og verifisere at 
forventet resultat nås. Et eksempel på en slik test er testing av opprettelse av et 
bildeobjekt tilhørende en egendefinert bildeklasse, hvor klassen kan holde på enten en 
url eller en fil. Implementasjonen av en slik test vises i figuren under. 


8 test("Create an image with provided url successfully", () ( 


9 Image img = Image(url: "testurl", file: null); 


19 expect(img.url, "testurl"); 

11 expect(img.file, null); 

12 D; 

13 test("Create an image with provided file successfully", () ( 
14 XFile testFile = XFile.fromData(base64Decode("sourcesz")); 


15 Image img = Image(url: null, file: testFile); 


16 expect(img.file, testFile); 

17 expect(img.url, null); 

18 DD: 

19 

20 test( 

21 "Create an image without providing an url or a file " 
22 "should fail and throw an assertionerror", () ( 

23 expect(() I 

24 Image(url: null, file: null); 

25 ), throwsassertionerror); 

26 D:; 

27 

28 test("Create an image with url and file should fail and throw assertionerror", 
29 OG 


30 expect(() I 
1 Image(url: "testurl", file: XFile.fromData(base64Decode("sourcesz"))); 
32 ), throwsassertionerror); 


D: 


E 


Figur 4.99: Enhetstest Image 
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4.10.2 Systemtesting 

Basert på resultatmål og de funksjonelle og ikke-funksjonelle kravene som ble fastsatt 
tidlig i prosjektet, ble det utarbeidet en systemtest for å undersøke hvor godt systemet 
oppfyller dem. Testingen ble utført som Black-Box testing hvor koden ikke var i fokus, 
men brukerens opplevelse og utførelse av oppgaver ble evaluert. Under vises en oversikt 
over de 5 første funksjonelle kravene til mobil og webapplikasjonen i tillegg til de ikke- 
funksjonelle kravene. Den fullstendige testen med alle resultater kan finnes i vedlegg S. 


Krav Utført Kommentar 


Funksjonelle krav 


Mobilapplikasjon 


En bruker skal kunne 
opprette en profil for å 
benytte systemet 


En bruker med profil skal 
kunne aksessere systemet 
med sin epost og passord 


Per i dag slettes brukeren 
med all relevant data de 
har registrert. Optimalt kan 
brukeren slettes, og 
oppsynsdataen kan 
beholdes anonymisert 


En bruker skal kunne slette 
sin profil 


En bruker skal kunne endre 
sin profilinformasjon 


En bruker skal kunne se de 
nyeste turene som er blitt 
gjennomført 


Webapplikasjon 


En bruker skal kunne 
opprette en profil for å 
benytte systemet 
En bruker med profil skal 
kunne aksessere systemet 
med sin epost og passord 
En bruker skal kunne slette 
sin profil 


Per i dag slettes brukeren 
med all relevant data de 
har registrert. Optimalt kan 
brukeren slettes, og 
oppsynsdataen kan 
beholdes anonymisert 


En bruker skal kunne endre 
sin profilinformasjon 


En bruker skal kunne se 
detaljer om turen etter 
fullført tur 
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Ikke funksjonelle 


Målt gjennom 
sammenligningstest 


Raskere å generere 
rapporter enn ved manuell 
opprettelse 


Målt ved samtale med 
domeneekspert 


Enklere å finne 
beitedata/dyredata om din 
gård enn uten systemet 
Raskt å laste inn data Under 1 sekund for 
innlasting av data og 
visning av alle sider i 


applikasjonen 


Følger gjeldende lover og 
regler angående 
personvern og GDPR 


Lagring gjennomføres på 
under 2 sekunder lokalt og 
på under 10 sekunder til 
skyen. 


Data lagres sikkert og 
effektivt 


Tabell 4.12: Oversikt over noen av testkriteriene i systemtesten 
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5 Resultater 


5.1 Endelig brukertest av løsningen 


Ved slutten av utviklingsperioden ble det gjennomført en endelig brukertest av løsningen 
for å evaluere om brukerne oppfattet systemet som brukbart, tilstrekkelig og oppfylte 
deres forventninger. Testen ble gjennomført på samme måte som de tidligere 
brukertestene i prosjektet ved først å gi brukeren litt informasjon om hvordan testen 
kom til å gjennomføres, før han/hun ble presentert for løsningen. Hva brukeren ble 
informert om før starten av testen finnes i vedlegg H. Etter at informasjonen var gitt ble 
brukeren gitt tilgang til applikasjonen og fikk lest opp oppgaver han/hun skulle 
gjennomføre. Alle disse spørsmålene i tillegg til brukernes svar på spørsmål som ble stilt 
etter den gjennomførte testen kan finnes i vedlegg T. 


Testen ble gjennomført med tre generelle testere og domeneeksperten. Gjennom testen 
ble brukerne bedt om å utføre forskjellige oppgaver i systemet og registrere saueflokker 
de ble vist på papir mens de gikk en predefinert «oppsynsrunde» under observasjon. 
Figuren under illustrerer en saueflokk brukeren ble vist i løpet av testen. 


ÅRA JA 


0 %G 


Figur 5.1: Illustrasjon av saueflokk vist til brukeren under endelig brukertest 


Et element i testen som var vanskelig å simulere er utfordringen med å registrere sauer 
på lang avstand hvor brukeren observerer dem gjennom kikkert og sauene er i 
bevegelse. Dette scenarioet måtte derfor gjennomføres ved at brukeren ble fortalt at 
han/hun ikke kunne observere noe annet ved sauene enn hvor mange de var og at de 
hadde en hvis farge. 


Tabellen under gir en oversikt over utfordringene som ble avdekket under den endelige 
brukertesten av systemet. EP1 står for «Endelig brukertest problem 1» og EL1 står for 
«Endelig brukertest løsning». 
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Sammendrag av endelig brukertestresultater, Mobilapplikasjon 


Bruker 


Problem 


Foreslått Løsning 


Domeneekspert 


EP1: Noen problemer med å 
forstå bruken av de runde 
knappene i applikasjonen 


EL1: Fant ut av dette og mente 
selv i ettertid at knappene var 
logiske -> ingen løsning 


Generell bruker 1 


EP2: Usikkerhet rundt «last 
ned kart» knappen og om 
dette er et nødvendig sted i 
start tur prosessen 


EL2: Legge til forklarende tekst 
for å indikere at å laste ned kart 
er nødvendig 


Generell bruker 1 


EP3: Problem med å skjønne 
hvilken vei knappen i 
kikkertmodus skal sveipes for 
å registrere sauer 


EL3: Endre retning på sveipingen? 


Generell bruker 1 


EP4: Eget felt for totalt antall 
sauer var forvirrende 


EL4: Etterspurt av domenebruker. 
Kan behøve funksjonelt redesign 
og nye brukertestingsrunder 


Generell bruker 1 


EP5: Vanskelig å se hvilken 
type sau som er aktiv visuelt i 
kikkertmodus 


EL5: Bruke bakgrunnsfarge eller 
liknende for å utheve den aktive 
kategorien 


Generell bruker 2 


EP6: Usikkerhet rundt last 
ned kart funksjonaliteten 


EL6: Se EL2. 


Generell bruker 2 


EP7: Usikkerhet rundt «Start 
tur» knappen da den kun viste 
et kart 


EL7: Legge til et pluss ikon for å 
indikere at man starter noe nytt 


Generell bruker 3 


EP8: Fant ikke umiddelbart 
den gjennomførte turen for 
opplasting til skyen 


EL8: Vise et ett tall på 
navigasjonsbaren for å indikere at 
det er noe som venter på 
brukeren i profilen deres 


Generell bruker 3 


EP9: Tannhjulet var ikke 
intuitivt for å indikere gamle 
turer 


EL9: Utforske andre 
ikonalternativer 


Tabell 5.1: Sammendrag av endelig testresultater for mobilapplikasjonen 


Sammendrag av endelig brukertestresultater, Webapplikasjon 


Bruker 


Problem 


Foreslått Løsning 


Generell bruker 3 


EP2: Flokkene i kartet kunne 
fungert som «velgere» av 
flokk i løsningen 


EL2: Gjøre det tydelig i kart og 
sidemeny hvilken flokk som er 
valgt og la brukeren endre dette 
ved å klikke på flokker i kartet 


Tabell 5.2: Sammendrag av endelig testresultater for webapplikasjonen 


Tilbakemeldingene fra brukertesten var stort sett positive, og alle brukerne kom seg 
gjennom oppgavene relativt enkelt uten store problemer. I tillegg fikk systemet mange 
positive tilbakemeldinger fra brukerne i intervjuene etter testen. Flere av brukerne ytret 
at de syntes applikasjonen var enkel i bruk og at de syntes det visuelle uttrykket var 
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appellerende. Det kom likevel en del tilbakemeldinger på designvalg eller enkeltløsninger 
i applikasjonene som kan forbedres. Disse kommer ikke til å bli utbedret gjennom dette 
prosjektet, men vil være tema for videre utvikling av systemet. 


5.2 Sammenlikningstest 


I tillegg til å gjennomføre brukertesting av mobil og webapplikasjonen gjennomførtes det 
tester av mer tradisjonelle oppsynsverktøy for å gi et sammenlikningsgrunnlag for det 
utarbeidede systemet. De samme spørsmålene og oppgavene ble gitt til brukerne og de 
ble bedt om å gå den samme predefinerte turen. I denne test runden fikk derimot 
brukerne registrere observasjonene sine med penn og papir i stedet for 
mobilapplikasjonen og NSGs foreslåtte Excel ark for generering av rapport i stedet for 
Webapplikasjonen (NSG). 


Igjen var det slik som i forrige test vanskelig å simulere utfordringen med å registrere 
sau på lang avstand med kikkert uten at dyrene står stille. Det ble derfor igjen simulert 
ved å opplyse brukeren om at han/hun ikke kunne se annet enn antall dyr og fargen på 
dem. Dette gir likevel ikke den helhetlige opplevelsen av vanskelighetene med å måtte se 
ned på arket for å så finne igjen flokken med kikkert etterpå. 


Sammenlikningene av de «manuelle» løsningene og det utviklede systemet er basert på 
tid det tok brukerne å registrere flokker og hendelser, tid det tok brukerne å generere en 
rapport og brukernes egne tilbakemeldinger på de opplevde forskjellene ved å benytte 
systemet og ikke. Tabellen under presenterer de målte gjennomføringstidene for hver 
oppgave. 
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Tid ved bruk av Tid ved bruk av 
Bruker Oppgave i 
manuelle løsninger systemet 
Bruker 1 
Registrering av en 02m 135 0Om 375 
flokk 
Registrering av en 01m 045 0Om 325 
hendelse 
Generering av 03m 225 0Om 075 
rapport 
Bruker 2 
Registrering av en O1im 435 0im 025 
flokk 
Registrering av en O1im 365 00Om 455 
hendelse 
Generering av 02m 435 00m 095 
rapport 
Bruker 3 
Registrering av en Oim 515 0Om 585 
flokk 
Registrering av en 02m 01s 0im 12s 
hendelse 
Generering av 02m 065 0Om 13s 
rapport 


Tabell 5.3: Oversikt over tid brukt på forskjellige oppgaver 


De målte tidene gjennom sammenligningstesten viser at alle registreringer ble 
gjennomført raskere ved bruk av det utviklede systemet i forhold til bruk av manuelle 
løsninger. Flere brukere uttalte at de syntes det å skrive for hånd var tungvint og at de 
ikke i ettertid var sikre på hva de selv hadde notert ned. En av brukerne sa også at han 
kunne se for seg at det hadde blitt ende verre om flokken hadde vært på flere dyr (I 
denne testen fikk de bare beskjed om å registrere 6stk) og at han muligens ikke hadde 
orket å stå ute i dårlig vær og registrere detaljer om dyrene for hånd. I tillegg opplevde 
to av brukerne at det regnet under testen, noe som gjorde det å bruke notatbok til å 
registrere ble ekstra utfordrende. Figuren under viser en av brukernes notater etter en 
oppsynsrunde med registrering av tre flokker og en hendelse og den samme turen 
registrert ved bruk av mobilapplikasjonen. 
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& ans Karlsen 
28.14.2022 19:14 


ppdalsgruppa 


Flokker 
Flokk 1 
) sal * 3 lar 


Flokk 2 
) sau * 3 lar 


Figur 5.2: Notater ved registrering av sau Figur 5.3: Registrert tur ved hjelp av 
med penn og papir mobilapplikasjon 


Noen av tilbakemeldingene som ble gitt etter å ha gjennomført den samme testen med 
mobilapplikasjonen var at det var mer oversiktlig, raskere å benytte seg av og at 
oversikten etter den gjennomførte turen var mye enklere å forholde seg til enn ved bruk 
av penn og papir. Det ble også nevnt at man ved bruk av notatbok ikke hadde mulighet 
til å se hvor man hadde gått tidligere eller hvor man hadde gått når man var ferdig på 
tur, og at man ikke fikk registrert posisjonen til saueflokkene. 


Sammenligningstesten av webapplikasjonen ble gjort med fokus på hvor raskt en bruker 
kan generere en rapport basert på beitesesongens observasjoner. Ved bruk av den 
manuelle løsningen ble brukeren bedt om å fylle inn turens registrerte detaljer i et Excel 
ark som NSG tilbyr som en standard for digital organisering av oppsynsturer (NSG). 
Excel arket har flere sider hvor brukeren blir bedt om å fylle inn info, men for denne 
testen lot teamet brukerne konsentrere seg om de tre første, da fjerde side fokuserer på 
utregning med tanke på tap som testbrukerne ikke har forutsetninger for å gjennomføre 
uten opplæring. Brukerne fikk sjansen til å gjøre seg kjent med Excel arket på forhånd 
før testen startet og tiden ble stanset når turen var fylt inn og de var klare til å skrive ut 
en rapport. Når webløsningen ble evaluert fikk brukeren beskjed om å gjøre det som 
skulle til for å generere en rapport med systemet. Ved å se på tidene på 
gjennomføringene med hver løsning kan man se at brukerne gjennomsnittlig sparte 2m 
og 34s ved å gjennomføre genereringen av rapport via webløsningen. Dette er primært 
fordi webløsningen ikke krever noen form for utfylling, men er basert på allerede 
registrert data i mobilapplikasjonen. 
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11 dagsverk = 7,51) og overføres til skjema ar. & Oppsum. Arbeidsinasats NES 
ah > Å va 
er hver hver. Gult felt susrane 


senløpense 


EE riket a———— Eee (ID dyr, eier, lokalitet, 1 
Dato tapsårsak), løshunder, kråkefugl, uro i flokk, personer kontaktet, km kjørt 
0.mm.88åå | Venlig (VJJexstre (E) Tklokkestett m.m) 


28.05.2022 20 min Rundt nabolag: Død Sau, Eier ukjent, mulig rovdyr 


1. Beiteslipg | utmark 2. Tilsynslogg 3. Tapsårsaker - kadaverfunn 4. Oppsum. tap av dyr 5. Oppsum. arbeidsinnsats 6. Sanking Annet ar ... 


Figur 5.4: Excel ark for manuell generering av oppsynsrapport 


Tilbakemeldingene fra brukerne ved bruk av Excel til generering av rapport ved utfylling 
av detaljer om den gjennomførte turen viste at flere syntes det var tungvint å bruke og 
at det ble mye dobbeltregistrering av informasjon. En bruker nevnte også at hun ikke 
syntes dataen ikke var ryddig å lese etter registreringen var gjennomført. Til 
sammenlikning fikk webapplikasjonen gode tilbakemeldinger fra alle brukerne om at 
løsningen var rask og enkel å bruke og at rapporten som ble generert var enkel å lese. 


115 


6 Diskusjon 


6.1 Evaluering av prosessen 


For evaluering har prosjektprosessen blitt delt opp i fire faser. Undersøkelsesfasen, 
Designfasen, utviklingsfasen og testfasen. 


Undersøkelsesfasen 


Undersøkelsesfasen bestod av å jobbe med domenekunnskap og skaffe en oversikt over 
allerede eksisterende løsninger. Dette ble gjort gjennom samtaler med domeneekspert 
og undersøkelser via tilgjengelige ressurser på nett. 


Teamet fant det utfordrende å få god innsikt i hvor mye eksisterende løsninger faktisk vil 
koste en bonde og å gjøre en kostnadsanalyse av totalprisen en bonde vil måtte betale 
for å benytte seg av de forskjellige alternativene. Flere av løsningene faller innunder 
ordninger hvor bønder kan få tilskudd fra staten for å subsidiere innkjøp og bruk for å 
øke dyrevelferden. Hvor mye disse tilskuddene er på er varierende og det er flere 
instanser som potensielt subsidierer innkjøp av elektronisk sporingsutstyr (Findmy). 
Noen av løsningene gir også prisavslag for innkjøp av store kvantum i tillegg til at 
prisene vil variere over årene avhengig av om man kjøper inn bjellene eller har dem 
gjennom en leasingavtale. 


Det er også utfordrende å beregne hvor mye en bonde vil tjene på dyrene sine vedd slakt 
hvert år, da dette i stor grav avhenger av bondens antall dyr, hvor mange tap han/hun 
har gjennom sesongen og hvor fete dyrene har blitt ved sesongslutt. 


Det ble likevel funnet informasjon som kunne gi en grunnleggende oversikt over priser 
og størrelsesforhold. Det ble også slått fast at det ikke finnes noe alternativ på markedet 
som dekker det behovet denne oppgaven utforsker og forsøker å komme med en løsning 
på. 

Designfase 


Gjennom designfasen ble det utarbeidet flere prototyper for å evaluere design og 
brukervennlighet av løsningen. Designet ble i stor grad påvirket av brukernes 
tilbakemeldinger og det å gjennomføre flere iterasjoner av brukertesting og prototyping 
viste seg å ha god effekt da man oppdaget nye utfordringer og muligheter for forbedring 
ved hver iterasjon. Man fant også ut av ting som virkelig fungerte godt ved løsningen og 
godt og grundig arbeid gjennom denne fasen sparte teamet for uønskede overraskelser 
gjennom utviklingsfasen og ved den endelige brukertesten. 


Utviklingsfase 


Gjennom utviklingsfasen arbeidet teamet godt og effektivt sammen og bruken av Kanban 
som utviklingsmetodikk hjalp teamet å strukturere både tid og oppgaver. Bruken av 
Github project boards for å holde oversikt over oppgavene som skulle gjennomføres viste 
seg å være svært effektivt og bruk av pull requests for å sikre kodekvaliteten fungerte 
godt ved at flere bugs ble oppdaget underveis. Teamet har lært svært mye gjennom 
denne prosessen både kodemessig, arkitekturmessig og samarbeidsfaglig. 
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Utviklingsperioden endte opp med å bli noe lengre enn teamet på forhånd hadde estimert 
da det oppstod uventede utfordringer underveis som tok noe lengre tid å løse enn det 
hadde blitt estimert. I tillegg var begge teammedlemmene dedikert til å produsere et så 
komplett system som mulig og utviklingstiden ble på bakgrunn av dette utvidet noe. 


En teknisk utfordring teamet har hatt gjennom utviklingen er ustabilitet i strømming av 
oppdateringer til kartet mens en bruker beveger seg eller kartet skal instansieres på 
iPhone. Kartet vil lastes til siden, men det er tidvis utfordringer med å vise brukerens 
posisjon i kartet. 


En annen utfordring teamet har hatt har vært stabilitet i nedlasting av kart, hvor 
løsningen tidvis ikke klarer å laste inn kartet som blir lagret ved starten av en tur. 
Mobilapplikasjonen vil falle tilbake på kartløsning som hentes via web, så dette blir først 
et problem når man befinner seg utenfor mobildekning. 


Testfase 


Det ble gjennomført flere brukertester gjennom prosjektet, både før og etter 
utviklingsfasen. Gjennomføringen av brukertestene viste seg å være mer tidkrevende 
enn det teamet opprinnelig hadde estimert. Dette gjorde at utviklingsfasen ble forskjøvet 
noe. Utføringen av brukertestene ble imidlertid gjennomført på en tilfredsstillende måte 
og produserte en rekke nyttige resultater for både dokumentasjon og videreutvikling av 
systemet. I ettertid vurderes det at det skulle ha vært utført enda en brukertest av 
løsningen midtveis i utviklingsperioden for å få tilbakemeldinger på det utviklede 
produktet underveis. 


Testplanene som ble utarbeidet for brukertestene sikret at alle brukerne fikk den samme 
informasjonen og hadde de samme forutsetningene når de skulle gjennomføre testene. 
Det viste seg også å være effektivt å designere roller til teammedlemmene under 
utførelsene av testene slik at man gikk glipp av så få detaljer som mulig. 


6.2 Evaluering av løsningen 


For å evaluere det utviklede systemet vil det bli tatt utgangspunkt i den endelige 
brukertesten av systemet og sammenligningstesten som ble gjennomført ved endt 
utviklingsperiode. Basert på dataen som ble innhentet gjennom disse brukertestene vil 
systemet evalueres i relasjon til de utformede forskningsspørsmålene i avsnittet «Mål og 
problemstilling». 


Forskningsspørsmål 1: 


Hvor mye mer effektivt er det å registrere observasjoner ved hjelp av Beitemaster i 
motsetning til med dagens metoder? 


Systemet Beitemaster ble utviklet som et alternativ til manuelle metoder for registrering 
av sau på utmarksbeite. Hovedmålet var å effektivisere gjennomføringen av 
oppsynsturer og genereringen av rapporter for søknader om erstatning for tapte 
beitedyr. Gjennom den endelige brukertesten som er dokumentert i avsnittet 
«Resultater», ble det funnet at ved registrering av en utvalgt hendelse sparte 
testpersonene i gjennomsnitt 44 sekunder. Ved registrering av en utvalgt flokk sparte 
testpersonene i gjennomsnitt 1 minutt og 3 sekunder. Disse funnene var noe 
overraskende for teamet da deres personlige hypotese var at ettersom notattakning er 
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noe som er kjent for alle, ville dette være raskere enn å benytte appen for første gang. 
Dette var fordi testerne ikke ville være kjent med systemets brukergrensesnitt fa før av. 
Dette var derimot ikke tilfellet, noe som var en positiv overraskelse i systemets favør. 
Sannsynligvis vil forskjellen i tid også øke ettersom brukerne blir mer kjent med 
systemets brukergrensesnitt. 


Selv om 44 sekunder raskere for hver hendelse og 1 minutt og 3 sekunder raskere per 
flokk ikke nødvendigvis høres mye ut for seg, vil dette utgjøre betydelig tid på en tur 
med mange flokker og hendelser. I tillegg til de konkrete tidsmålingene av de forskjellige 
registreringsprosessene, omtalte flere av brukerne den manuelle løsningen som tungvinn 
og tidkrevende å benytte seg av. 


På bakgrunn av disse funnene konkluderer teamet med at systemet som er utarbeidet er 
mer effektivt for registrering av observasjoner enn dagens metoder. Konkret sparer det 
brukere ca. 1 minutt per registrering under en oppsynstur. 


Forskningsspørsmål 2: 


Hvor presis, detaljert og tilstrekkelig er informasjonen registrert ved hjelp av Beitemaster 
sammenliknet med dagens metoder? 


Gjennom den endelige brukertesten ble fullstendighet av dataen som ble registrert i løpet 
av en oppsynstur ved hjelp av mobilapplikasjonen evaluert. En av oppgavene som ble 
gitt til testpersonene var å aksessere den gjennomførte turen man lastet opp til skyen 
gjennom webapplikasjonen og evaluere at den registrerte dataen stemte overens med 
hva de registrerte i appen. Alle testpersonene fant at dataen de hadde registrert i appen i 
løpet av oppsynsturen stemte overens med dataen som ble fremvist i webapplikasjonen. 


Gjennom intervjuene gjort i etterkant av den endelige brukertesten ble det gitt 
tilbakemelding fra flere av testbrukerne at informasjonen de fant på siden for 
gjennomførte turer føltes fullstendig, utfyllende og tilstrekkelig. Dette ble også nevnt av 
domenebruker flere ganger gjennom utførelsen av testen. I tillegg til dette ble det uttrykt 
av en testbruker at han neppe hadde orket å registrere like mange detaljer med papir og 
blyant som han kunne gjøre med applikasjonen, fordi det ville tatt for lang tid og vært for 
mye arbeid. 


På bekgrunn av funnene gjort gjennom testing, samtaler og intervjuer med 
testsubjektene finner teamet at dataen registrert via appen er svært presis, mer detaljert 
enn ved registrering med penn og papir og mer enn tilstrekkelig for domenebruker. 


Forskningsspørsmål 3: 


Hvor mye mer effektivt er det å produsere rapporter ved hjelp av Beitemaster i 
motsetning til ved tradisjonelle metoder? 


Ved gjennomføring av sammenligningstesten ble det målt hvor mye raskere det var for 
brukere å generere en rapport ved hjelp av systemet, sammenliknet med det digitale 
alternativet NSG tilbyr via et standardisert Excel ark. For å kunne produsere en rapport 
etter gjennomført oppsynstur med NSGSs løsning var brukerne nødt til å fylle ut data om 
turen i arket, hvor det totale antallet sau, hendelser og så videre, ble regnet ut. 

Brukerne ble gjennom testen kun bedt om å fylle ut 3/6 sider i Excel arket, da flere av de 
siste sidene består av mer komplekse utfyllingsmønstre. Flere brukere ytret gjennom 
testen at det føltes tungvint å måtte registrere dataen de hadde skrevet ned på papir på 
nytt i arket og flere opplevde at det var krevende å forstå hvordan informasjonen skulle 
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fylles ut. Ved hjelp av Beiteweb kunne brukerne generere rapporter direkte, basert på 
informasjonen som allerede var registrert i løsningen ved bruk av mobilapplikasjonen. 


Ved bruk av Beiteweb til generering av rapport sparte brukerne i gjennomsnitt 2 minutter 
og 34 sekunder. Det er her også viktig å bemerke at gjennom testen ble brukerne kun 
bedt om å registrere tre flokker og en hendelse fra den gjennomførte oppsynsturen. 
Dette er et urealistisk lavt tall for en virkelig oppsynstur. Gjennom sesongen vil tiden det 
tar å registrere denne dataen etter hver tur utgjøre betydelig større tidsbruk da det vil 
være flere turer, flere flokker og flere hendelser å registrere, i tillegg til at man bør fylle 
ut det fullstendige skjemaet. 


Om man antar at det tar brukeren minst like lang tid å registrere en tur som det i 
gjennomsnitt tok testpersonene i den endelige brukertesten, og sauene er på beite i ca. 
20 uker hver sesong, kan man estimere at brukeren vil spare minst 51m 205 per sesong 
ved registrering med Beitemaster, men tallet er sannsynligvis betydelig høyere. 


Forskningsspørsmål 4: 


Hvor godt dekker Beitemaster brukernes behov når det kommer til oppfølging av sau på 
utmarksbeite? 


Gjennom alle de gjennomførte testene gjennom dette prosjektet har brukernes behov 
stått i fokus. Hver brukertest har bidratt til å avdekke potensiale for forbedring av 
løsningen og hvordan brukernes behov bedre kunne dekkes. Ved slutten av hver test har 
brukerne også fått mulighet til å uttale seg om elementer de har savnet eller kunne sett 
for seg i løsningen. Ved utførelsen av den endelige brukertesten var tilbakemeldingene 
utlukkende UI-fokusert og alle brukerne mente datagrunnlaget og brukervennligheten av 
systemet var meget god. Domeneeksperten uttalte at systemet var ett av de beste han 
hadde sett av sitt slag og at det dekket alle hans behov på oppsynstur, i tillegg til å tilby 
funksjonalitet han ikke selv hadde tenkt på. 


Den utførte systemtesten som er beskrevet i «Systemtesting» validerte at systemet 
oppfyller alle utenom 2 av de funksjonelle og ikke-funksjonelle kravene helt, og disse 2 
ble oppfylt delvis. 


Basert på tilbakemeldinger fra brukere gjennom prosjektet og ved prosjektets slutt, 
domeneekspertens vurderinger, i tillegg til evalueringen av systemet gjennom 
systemtesten vurderer teamet at systemet oppfyller brukernes behov svært godt. 


6.3 Måloppnåelse 
Resultatmål 


Tidlig i prosjektfasen ble det utarbeidet resultat og effektmål for systemet. 
Resultatmålene bestod av å oppnå definert funksjonalitet for mobil og webapplikasjon, 
gjøre systemet tilgjengelig for alle brukere i målgruppen og sikre at systemet følger 
gjeldende krav til GDPR. 


Mobilapplikasjonen og Webapplikasjonens endelige funksjonalitet er presentert og 
diskutert i «Produkt» seksjonen i rapporten. Alle de definerte kravene til begge 
applikasjoner er implementert og gjennomført etter de utarbeidede kravspesifikasjonene. 
Gjennom systemtesten som er presentert i avsnittet «Systemtesting» og som finnes i sin 
helhet i vedlegg S, ble kravene og resultatmålene relatert til systemfunksjonalitet 
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evaluert. Funnene gjennom denne testen viste at alle kravene og målene på dette 
området er oppfylt med unntak av 2 punkter relatert bevaring av data ved sletting av en 
bruker. 


I seksjonen om «Teknologivalg» og diskusjonen om valg av Flutter som utviklingsverktøy 
begrunnes valget av Flutter med at det støtter både Android og iOS plattformene, som 
over 99% av mobilbrukerne i Norge og 98% på verdensbasis benytter seg av. I tillegg 
oppfyller Flutter de tekniske kravene som ble satt til systemet ved at det støtter 
operativsystemer for både telefoner som kjører Android 9 eller senere og iOS 12 eller 
senere. På bakgrunn av dette anser teamet målgruppen for produktet som nådd. Det vil 
likevel alltid finnes enkeltindivider som ikke vil nås av løsningen som for eksempel 
mennesker som ikke benytter seg av telefon eller som kjører så gamle operativsystemer 
at Apple og Google ikke lenger støtter dem. 


GDPR har vært et fokus gjennom utvikling av systemet og som diskutert i seksjonen om 
«GDPR og personvern» har teamet fulgt gjeldende retningslinjer og tilrettelagt systemet 
for etterfølgelse av norsk personvernlov. 


Effektmål 


Effektmålene omfattet å forenkle og effektivisere registrering av observasjoner, fullførte 
oppsynsturer og generering av rapporter for innsendelse til Miljødirektoratet. I tillegg 
skulle systemet bidra til å gjøre det enklere å holde oversikt over beitelagets felles data 
og sine egne sauer og tapstall. 


Gjennom evalueringen av løsningen gjort i seksjonen over, hvor forskningsspørsmålene 
ble besvart, ble det diskutert at den endelige brukertesten og sammenligningstesten 
viste at det er enklere og raskere for brukere å registrere observasjoner under en 
oppsynstur enn tidligere. Det er også eklere å registrere gjennomførte turer og enklere 
og mer effektivt å generere en rapport enn med de tradisjonelle metodene. 


Det siste effektmålet har var vanskelig å måle i løpet av prosjektperioden og må 
evalueres av oppsynspersoner som tar løsningen i bruk over tid. Men basert på 
domeneekspertens opplevelser av hvordan opplysninger deles mellom bønder i dag, 
enten ved hjelp av delte dokumenter eller ved eksplisitt kommunikasjon rundt temaet, er 
det nærliggende å tro at systemet oppfyller målet om å forenkle prosessen med å holde 
oversikt over sin egen og felles data. 
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7 Konklusjon og videre arbeid 
7.1 Konklusjon 


Hovedmålet gjennom dette prosjektet var å utvikle et system som kunne hjelpe 
oppsynspersoner og bønder ved å forenkle deres hverdag i løpet av beitesesongen og 
effektivisere prosessene rundt oppsynsturer og dokumentasjon. 


For å kunne nå dette målet har teamet gjennom prosjektperioden måttet bli kjent med 
domenet og logistikken rundt drift og hold av husdyr på utmarksbeite i Norge. Basert på 
research på området og samarbeid med domeneekspert og veileder professor Hvasshovd 
ble det utarbeidet kravspesifikasjoner og prosjektmål for systemet. Det ble nedsatt 4 
forskningsspørsmål som omhandlet hvor mye systemet kunne forbedre 
oppsynspersoners opplevelse og tidsbruk på oppsynsturer og ved generering av 
dokumentasjon for beitesesongen. 


De utarbeidede kravspesifikasjonene og resultatmålene la grunnlaget for modellering av 
brukerhistorier, applikasjonsflyter og en konseptuell modell som ble kritisk for systemets 
design. Designet ble deretter revidert i flere runder etter feedback fra brukere gjennom 
brukertester, før utviklingsperioden startet. 


På bakgrunn av arbeidet hittil ble systemarkitekturen utarbeidet, og modelleringen av 
databasen ble gjennomført. Valget av teknologier ble i stor grad påvirket av den 
definerte målgruppen, kravspesifikasjonene og brukeres tilbakemeldinger om ønsket 
funksjonalitet. Flere alternativer til teknologier ble evaluert før de endelige valgene ble 
tatt. Gjennom utviklingsperioden ble det utviklet en Webapplikasjon og en 
Mobilapplikasjon med en felles backend tjeneste med felles database. Teamet fikk 
arbeide med flere utviklingsspråk og teknologier, og hadde fokus på testskrivning og 
sikkerhet underveis. 


Ved slutten av utviklingsperioden ble det gjennomført endelige brukertester og en 
sammenligningstest av hvordan systemet målte seg i tidsbruk sammenlignet med dagens 
tilgjengelige løsninger. Basert på disse testene ble forskningsspørsmålene besvart og 
måloppnåelsen til systemet evaluert. 


Ved besvarelsen av forskningsspørsmålene ble det vist at; 


- Systemet er mer effektivt ved registrering av observasjoner på oppsynstur enn 
ved tradisjonelle metoder og at det sparer brukere ca. 1 minutt per registrering 
under en oppsynstur. 

- Systemet er svært presist, mer detaljert enn ved registrering med penn og papir 
og mer enn tilstrekkelig for domenebruker. 

- Systemet er mer effektivt for generering av rapporter enn ved bruk av 
tradisjonelle metoder og Beiteweb sparte brukerne i gjennomsnitt 2 minutter og 
34 sekunder ved generering av en rapport. Dette tallet vil sannsynligvis være 
høyere for en reell oppsynstur. 

- Systemet oppfyller brukernes behov svært godt. 


Ved evaluering av systemets måloppnåelse ble det vist at alle systemets resultatmål ble 
møtt på en tilfredsstillende måte. Systemets effektmål ble også i stor grad innfridd 
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utenom målet om å forenkle prosessen med å holde oversikt over sin egen og felles data. 
Dette målet viste seg vanskelig å måle gjennom prosjektprosessen og må måles over tid 
ved bruk av applikasjonen hos reelle beitelag. 


Teamet har arbeidet selvstendig og uavhengig av andre entiteter og har dermed i stor 
grad fattet egne beslutninger og avgjørelser rundt prosjektet. Det endelige systemet er 
et helhetlig fungerende system med et gjennomarbeidet designutrykk som innfrir de krav 
og mål som ble fastsatt ved starten av prosjektet. Det er vist at systemet er mer 
effektivt enn tradisjonelle metoder og det har fått gode tilbakemeldinger både fra 
testsubjekter og domeneekspert. Dette tyder på at utviklingen har resultert i et godt 
produkt som brukerne opplever som nyttig. 


7.2 Videre arbeid 


Selv om det endelige systemet møter målsetningene og brukernes forventninger er det 
flere områder som kan forbedres og utvikles videre. 


Testing i reelle scenarioer 


Løsningen ble aldri testet i et fullstendig reelt scenario i ekte beitelag ettersom oppgaven 
pågikk utenfor sesong og domeneeksperten ikke hadde tilgang på domenetestere. Dette 
er noe som burde gjennomføres for å få flere tilbakemeldinger på systemet i relasjon til 
brukerne som faktisk skal benytte seg av løsningen. Dette vil også gjøre det mulig å 
evaluere systemets siste effektmål som i stor grad ikke ble evaluert gjennom 
prosjektperioden. 


Administrativ funksjonalitet i webapplikasjonen 


Per i dag finnes det ikke funksjonalitet for å oppdatere profilbilde, redigere grupper eller 
akseptere invitasjoner til beitegrupper i webapplikasjonen. Dette er funksjonalitet som 
hadde vært naturlig å implementere og som kunne bedret brukernes opplevelse av 
webapplikasjonen. På grunn av tidsaspektet for prosjektet ble ikke dette gjennomført, 
men markert som videre potensiale for applikasjonen. 


Utbedring av resultater fra endelig brukertest 


Det ble avdekket potensiale for forbedring av en del UI elementer gjennom den endelige 
brukertesten som det kan være aktuelt å utforske videre og forbedre basert på brukernes 
tilbakemeldinger. Noen av disse tilbakemeldingene omfattet visuelle elementer som var 
vanskelige å fange opp gjennom registrering av sau og hvilken vei brukeren måtte sveipe 
for å registrere sauer i kikkertmodus. 


Alternativer for generering av rapporter i webapplikasjonen 


Et annet område det kunne vært interessant å utforske er å gi brukeren mulighet til å 
velge hvilke datafelter som er interessante ved generering av rapporter. Dette kunne blitt 
gjennomført ved å gi brukeren tilgang til å fylle ut et mer utfyllende skjema før 
generering av rapport hvor man selv kunne bestemme hvilken data fra beitesesongen 
rapporten skulle inneholde. På denne måten vil brukeren ha mer kontroll over utforming 
av rapport og rapporten kan være nyttig i enda flere scenarioer enn per i dag. 
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Løsning av GPS og offline kart stabilitetsproblemer 


Ettersom teamet er klar over ustabiliteter i innlasting av brukerens posisjon i kartet på 
iPhone og ustabilitet i aksessering av offline kart ved bruk utenfor dekningsområder er 
dette områder som bør arbeides videre med for å oppnå en bedre løsning. 
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Vedlegg 


A. Gantt diagram 


Progression plan 


Progression plan masters project 2021/2022 


Planning/start up 

Startup meeting 

Planning 
Framework/Technology evaluation 
Research 

Administrative 

Supervisor meetings 
Development 

Paper prototyping 

Figma prototyping 

User testing 

Fundamental app setup 

Trip registration 

Mobile App main functionality 


Web App main functionality 


Stretch goals 

Report and Documentation 
Project diary 

Report 


Deadline Dec 15th 


B. Kravspesifikasjon 
Utarbeidet 07.09.2021 


Tekniske krav 


Må kjøre på både Android og iOS 

Må støtte android > Queen Cake 10 https://endoflife.date/android 

Må støtte iOS >= 12.4.x https://support.apple.com/en-us/HT201222 

Må ha søtte for gps 

Må kunne behandle og vise kartdata offline (Ønsket kartdata fra kartverket) 
Må kunne håndtere Text-to-speech/talemelding 

Må kunne håndtere loggføring uten internettilgang 

Må kunne laste opp loggdata i skyen via wifi 


Applikasjonskrav 


Støtte opprettelse av bruker og login 
Støtte opprettelse av beitegrupper med medlemmer og gårder 


Støtte logging av oppsynsturer med all relevant info 
Støtte nedlastning av kart over relevant beiteområde før en tur begynner 
Støtte registrering av antall lam og sau inkludert farge sett under oppsynstur 


Støtte fremvisning av beitegrupper med tilhørede informasjon og tidligere turer 


Støtte mulighet for registrering av detaljert info om sauen slik som sauens gård 


tilhørighet, antall lam det skal være i flokken basert på slips og identifisere om det 


er riktig antall lam i flokken. 
e Støtte mulighet for registrering av sau uten å måtte se på telefonen ved 
observasjon av sau mer enn 30 meter unna. 
e Støtte mulighet for å plassere en observert flokk i kartet under registrering. 
e Støtte for registrering av hvor oppsynsmann har gått gjennom runden. 


e Støtte opplasting av bilder fra tur (sau/flokk, død sau, levninger osv - også skadd 


Sau) 
e Støtte registrering av tid og dato (essensielt i alt av logging feks når man ser 
sauen, starter tur, tidspunkter en saueflokk blir observert i løpet av en tur) 


Støtte lagring av logg og dokumentasjon i skyen 

Støtte visning av beitekvalitet i kart over beiteområdene 

Støtte generering av rapporter på standardformat basert på beitesesongens 
hendelser 


Støtte generering av logg for oppsyns runden og fremvise relevant informasjon 


C. Applikasjonsflyt Mobilapplikasjon 


Register flock of sheep mm => ' 


="=s2555n HER 
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D.Applikasjonsflyt Webapplikasjon 
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E. Konseptuell Modell 


Konsepter 


Hvert konseptelement i applikasjonen representerer en entitet som benyttes i relasjon til 
andre entiteter for til sammen å utgjøre et system. Den konseptuelle modellens rolle er å 
sette entitetene i system slik at man enklere ser sammenhengene i systemet og kan 
forenkle relasjonene mellom dem. På bakgrunn av dette vil det forhåpentligvis bli enklere 
for sluttbrukeren å kartlegge systemet og relasjonene når de tar systemet i bruk. Hver 
entitet har en rekke attributter som til sammen utgjør entiteten. 


Bruker 
Bruker refererer til en bruker i systemet. En bruker inneholder data om systembrukeren 
som navn og hvilke grupper de tilhører. 


Attributter: 


- Epost 

- Fornavn 

- — Etternavn 

- — Bilder 

- Admin status 

- Gruppe affiliasjoner 
- — Utførte turer 


Operasjoner: 


- Endre eller slette profilen 
- — Endre administrator status 
- — Opprette beitegrupper 


Beitegruppe 

Beitegrupper er navngitte grupperinger av brukere som samarbeider om å gjennomføre 
oppsynsturer. Administratorer kan opprette gårder, invitere brukere og redigere data. 
Alle brukere kan registrere turer i gruppen og evaluere den registrerte dataen. 


Attributter: 


- Navn 

- — Medlemmer 
- Turer 

- — Gårder 


Operasjoner: 


- Endre eller slette informasjon 
- Legge til medlemmer 

- — Legge til gårder 

- — Registrere turer 

- — Evaluere data 


Gård 

Gård representerer en gård som er involvert i beitegruppen. Sauer og lam som 
registreres tilhører en gård og kan identifiseres ved fargen på lappen i øret som tilsvarer 
gårdens farge i gruppen. 


Attributter: 


- Navn 
- Farge 


Operasjoner: 


- Endre farge 
- — Endre navn 


Tur 


Tur representerer en oppsynstur en oppsynsperson foretar for en beitegruppe. Gjennom 
turen registreres informasjon om flokker og observerte hendelser. Posisjoner brukeren 
har vært registreres også. 


Attributter: 


- — Flokker 

- — Hendelser 
- — Distanse 

- — Posisjoner 


Operasjoner: 


- Registrere flokker 

- — Slette flokker 

- — Registrere hendelser 
- Slette hendelser 


Hendelse 

Hendelser er observasjoner eller hendelser som forekommer mens en bruker 
gjennomfører en oppsynstur. Brukeren registrerer hendelsen med en tittel, kategori og 
beskrivelse av hva som har skjedd. Det kan også legges til bilder av hva som har 
forekommet. 


Attributter: 


- — Tittel 

- Kategori 

- — Beskrivelse 
- — Posisjon 

- — Bilder 


Operasjoner: 


- — Registrere data om hendelsen 
- — Legge til/fjerne bilder 


Flokk 


Flokk er en observert gruppe med dyr under gjennomføringen av en tur. Når brukeren 


observerer en flokk registreres den på turen som gjennomføres. En tur kan inneholde 
mange sauer og lam i tillegg til notater om flokken og bilder som kan være relevante for 
dokumentasjon. 


Attributter: 


- Sauer 

- Lam 

- — Notat 

- — Posisjoner 
- — Bilder 


Operasjoner: 


- — Registrere sauer 

- Slette sauer 

- — Registrere lam 

- — Slette lam 

- — Legge til/fjerne bilder 


Lam 

Et lam har informasjon om hvilken farge det har på ullen, hvilken gård det tilhører ifølge 
øremerkets farge og om det er skadet. Man har også mulighet til å skrive et notat på 
lammet for ytterligere informasjon. 


Attributter: 


- Farge 

- — Merkefarge 
- — Tilstand 

- — Notat 


Operasjoner: 


- —Registrere/Endre data 


Sau 


En sau har informasjon om hvilken farge det har på ullen, hvilken gård det tilhører ifølge 
øremerkets farge og om det er skadet. Slipsets farge indikerer hvor mange lam sauen 
burde ha med seg ved beitesesongen. Man har også mulighet til å skrive et notat på 
lammet for ytterligere informasjon. 


Attributter: 


- Farge 

- — Merkefarge 
- — Slipsfarge 

- — Tilstand 

- Notat 


Operasjoner: 


- — Registrere/Endre data 


Designmetaforer 


Designmetaforen for mobilapplikasjonen som er valgt er en notatbok. Notatboken er den 
tradisjonelle måten å registrere data om en oppsynstur på. Bøndene vil tradisjonelt ta 
med seg en notatbok ut på tur og skrive ned data de observerer underveis. Ettersom 
hovedformålet med mobilapplikasjonen er å registrere slik informasjon er notatboken 
valgt som metafor. 


Designmetaforen for webapplikasjonen er en ringperm eller et Excel-ark. Tradisjonelt 
ville bøndene kopiere over data registrert når de returnerte fra tur enten til papir eller til 
et Excel-ark for å lagre det frem til de trenger å evaluere data eller sende inn 
dokumentasjon til myndighetene. Ettersom webapplikasjonens formål er å strukturere 
data for evaluering og generering av rapporter er dette designmetaforen som er valgt. 


Konseptoversettelse 


Denne seksjonen inneholder en oversikt over hvilke virkelig livs entiteter hver 
konseptuelle entitet kan oversettes til. 


Konseptuell entitet Virkelig entitet 

Bruker En oppsynsperson/bonde 

Beitegruppe Et beitelag 

Gård En Gård med sau på utmarksbeite 

Tur En Oppsynstur gjennomført av oppsynsperson 
Hendelse En hendelse som skjer under en oppsynstur 
Flokk En saueflokk 

Lam Et lam 

Sau En sau 


Relasjonell Modell 


Email 


First name 

Last name 
Picture 

Admin status 
Group affiliations 


Performed trips 


(0, n) (0,n) 
o Member o 
(1) (1,n) 


Grazing Group 


Name 


Members 0, n<<Belongs to, 


Trips 


Farms 


(0,n) 


(1) 


(1) 


(0,n) 


reates 
Perform 


(1) 


Trip 
Flocks 
— Distance 


Positions 


Events 


(0,n) 


Belongs to 


(1) 


Event 
Title 
Description 
Category 


Position 


Flock 
Sheep 
0,n Belongs to 1 Lambs 
Note 
Positions 
(0, n) 
1) 
Lamb 
Color 
Tag color 
Condition 
Note 


(0,n) 


Color 

Tie color 
Tag color 
Condition 


Note 


F. Persona 1 Hanne Hove 


Mal fra: TDT4180 HCI — 2021 


Bonde 30-40 


Hanne Hove 


Det handler om dyrene og mennesket 


37 


MLG (Miki Rendalen 


PVLGuNdskg Utadvendt 


Sosial 


Dyrekjær 


Bio 
Hanne er en dyrekjær og sosial bonde 
som er opptatt av at dyra skal ha det bra 


o 


på beite. Hun liker å samarbeide med 
andre om å yte best mulig i jobben sin og 
er opptatt av at dyrevelferden blir ivaretatt. 


Følge opp dyrene på beite og vite at de 
har det bra 

Ha det hyggelig på jobb og samarbeide 
med andre 

Passe på at dyrene spiser godt og er 
ivaretatt på best mulig måte 

Drive bærekraftig drift 


Frustrasjoner 


Kan ikke følge opp alle dyrene 

Mange sau blir tatt av rovdyr 

Vanskelig å vite hvor man skal gå for å 
se sauene og hvor de sist ble sett 


Motivasjoner 


GØNTNU 


Kunnskap for en bedre verden 


Personlighet 


Ekstrovert gd] 


Introvert 


Sensing å] Intuisjon 
Tenking [] Føling 
Dømming gå Oppfattelse 
Passiv ] Aktiv 
Loyal Flytende 
Oppførsel 

e Setter pris på å gjennomføre 


oppsynsturer og gjør det gjerne så hun 
kan observere sauene selv 

Arbeider gjerne sammen med andre 
Behandler sauene sine godt og er 
veldig investert i deres velferd 


Oppgavespesifikk seksjon 


o 


Vil ha en enklere måte å registrere 
observasjoner 

Vil ha tilgang til informasjon de andre 
bøndene har registrert så raskt som 


mulig 

Vil kunne dokumentere dyrenes 
velferd nøye 

Vil kunne se at andre bønder 


gjennomfører sine oppsynsturer på en 
god måte 


G. Persona 2 Odd Larsen 


Mal fra: TDT4180 HCI — 2021 


Bonde 50-60 


Odd Larsen 


Hardt arbeid er realt arbeid 


58 


Mee («ik Oppdal 


Innadvendt 


Hardtarbeidende Selvstendig 


Bio 

e Odd er en hardtarbeidende og 
selvstendig bonde som er opptatt av å 
gjennomføre oppgavene sine på en 
ordentlig måte i henhold til loven men er 
også opptatt av at ting skal være 
praktisk. 


Følge lover og regler om dyrehold på 
utmarksbeite 

Gjennomføre jobben sin på en effektiv 
måte 

Drifte på en skikkelig, men også 
profitabel måte 


Frustrasjoner 

Må forholde seg til andre som ikke 
gjennomfører oppsyn skikkelig 

For mye arbeid å produsere rapporter for 
dokumentasjon til myndighetene 
Vanskelig å finne igjen sau om høsten 


Motivasjoner 


GØNTNU 


Kunnskap for en bedre verden 


Personlighet 


leser oveife ad Timeie0verdd 
Sansing Å intuisjon 
Tenking å Føling 
Dømming ] Oppfattelse 
Passiv ] Aktiv 
Lojal [ Flytende 
Oppførsel 


e Gjør gjerne jobben selv for at den skal 
gjøres skikkelig 

e Arbeider effektivt 

e Behandler sauene sine godt og blir 
frustrert av tap ettersom det koster ham 
mye penger 


Oppgavespesifikk seksjon 

e Vil ha et felles system for strukturering 
av informasjon 

e Vil ha tilgang til informasjon om sine 
sauer så raskt som mulig 

e Vil ha en mer effektiv måte å generere 
rapporter til myndighetene på 

e Vil ha et system som er enkelt å bruke 


H. Testintroduksjon for brukertester 


I 


Introduksjoner av test administratoren og notat takeren 


2. Beskriv observasjonene som gjøres under testen for subjektet 


Informer subjektet om at det ikke kommer til å gis hjelp underveis i testen 
og at de oppfordres til å finne sine egne løsninger 

Informer testsubjektet om at det ok om man ikke finner svaret på en 
oppgave eller gjør feil underveis, det er også ok å avslutte testen om man 
ønsker 

Informer subjektet om at prototypen er en lo-fi prototype og at det ikke 
kan forventes at den er perfekt eller polert, det er lov å informere om ting 
som fremstår som forvirrende 

Be testsubjektet tenke høyt under testen og la administratoren vite hva 
som ligger bak besluttninger som tas. 

Introduser applikasjonen og formålet den er ment å løse 

Spør om subjektet har noen spørsmål 

Gi oppgavene til subjektet 


I. Oppgaver og spørsmål, Papirprototype 


Oppgavene under skal løses under testing av papirprototypen: 


1. 


Du er en bonde som nettopp har fått tilgang til dette systemet. Du er medlem av 
et beitelag som inkluderer to gårder og 4 oppsynspersoner. Opprett en gruppe for 
beitelaget og legg til en av gårdene og en av oppsynspersonene. 

Du skal ut på en oppsynsrunde for beitelaget. Start en ny oppsynstur for 
beitelaget ved navn Oppdalsgruppa. 

Ute på oppsynsturen observerer du en flokk sauer. Sauene er ganske langt unna 
og du er nødt til å benytte kikkert for å se dem. Registrer denne flokken mens du 
benytter kikkert for å se dem. (Instruert til å registrere uten å se på telefonen og 
får lest opp 1 brun sau og 3 brune lam) 

Fortsatt ute på oppsynsturen observerer du en ny flokk ganske nær deg. Registrer 
en ny flokk med 2 grå sauer med røde merker, hvor en av dem har et grønt slips 
og den andre har gult slips. I tillegg ser du 3 grå lam med røde merker. 

På turen observerer du et dødt dyr. Registrer dette funnet og avslutt deretter 
turen. 


Spørsmål stilt i etterkant av brukertesten: 


Domeneekspert: 


1. 


Hva tenkte du om flyten i applikasjonen? 

«Jeg syntes flyten ga mening, men det gir ikke mening å ha Gårder som et eget 
element man kan aksessere og jeg ble forvirret av hva man skulle finne om man 
aksesserte denne menyen. I tillegg var kikkert registreringen altfor detaljert. Man 
vil aldri kunne gå tilbake og registrere flere detaljer ettersom flokken beveger seg 
og man gjerne mister sauene man ser på underveis.» 

Var det noen knapper du var usikker på hva gjorde? 

«Nei, det eneste jeg tenkte på var at det fantes pluss knapper både på 
beitegruppe siden og å forsiden som kan gjøre det noe uklart hva hver pluss 
referer til men jeg synes likevel det var greit.» 


Test subjekt 1: 


1. 


2. 


Hva tenkte du om flyten i applikasjonen? 

«Jeg synes flyten fungerte bra, det eneste jeg var usikker på var hva Gårder var.» 
Var det noen knapper du var usikker på hva gjorde? 

«Nei» 


Test subjekt 2: 


1. 


Hva tenkte du om flyten i applikasjonen? 

«Jeg synes at det var veldig rotete og vanskelig å bruke kikkertregistreringen. 
Den var veldig lang, og det var mange detaljer tilgjengelig som ikke var relevant 
å registrere.» 

Var det noen knapper du var usikker på hva gjorde? 

«Nei, jeg syntes at knappene ga mening og jeg fant ut hva jeg skulle gjøre selv 
om papir er litt vanskelig å skjønne seg på siden alt er flatt.» 


J. 


Spørsmål og svar, 
Figma prototype 1 Mobilapplikasjon 


Oppgavene under skal løses under første testing av Figmaprototypen: 


6. 


10. 


Du er en bonde som nettopp har fått tilgang til dette systemet. Du er medlem av 
et beitelag som inkluderer tre gårder og 5 oppsynspersoner. Opprett en gruppe 
for beitelaget og legg til en av gårdene og en av oppsynspersonene. 

Du skal ut på en oppsynsrunde for beitelaget. Start en ny oppsynstur for 
beitelaget ved navn Oppdalsgruppa. 

Ute på oppsynsturen observerer du en flokk sauer. Sauene er ganske langt unna 
og du er nødt til å benytte kikkert for å se dem. Registrer denne flokken mens du 
benytter kikkert for å se dem. (Instruert til å registrere uten å se på telefonen og 
får lest opp 1 brun sau og 3 brune lam) 

Fortsatt ute på oppsynsturen observerer du en ny flokk ganske nær deg. Registrer 
en ny flokk med 2 grå sauer med røde merker, hvor en av dem har et grønt slips 
og den andre har gult slips. I tillegg ser du 3 grå lam med røde merker. 

På turen observerer du et dødt dyr. Registrer dette funnet og avslutt deretter 
turen. 


Spørsmål stilt i etterkant av brukertesten: 


Domeneekspert: 


De 


Hva tenkte du om flyten i applikasjonen? 

«Flyten fungerer bra, det var lett å navigere seg rundt og jeg syntes de 
forskjellige mulighetene tok meg dit jeg forventet å lande.» 

Var det noen knapper du var usikker på hva gjorde? 

«Nei, jeg syntes ikonene og teksten var intuitiv. Den store knappen på 
kikkertregistreringssiden var derimot ikke så intuitiv å bruke siden jeg trodde den 
skulle sveipes og ikke klikkes på.» 

Hadde kikkertmodus riktig mengde detaljer? 

«Jeg syntes detaljnivået var bra nå. Jeg skjønte ikke med en gang hvor jeg kunne 
gå ut av registreringen når jeg hadde registrert antall sauer.» 


Test subjekt 1: 


3 


4. 


Hva tenkte du om flyten i applikasjonen? 

«Syntes den var god. Hadde ikke problemer med å finne frem.» 

Var det noen knapper du var usikker på hva gjorde? 

«Var litt usikker på hva knappen for å bytte mellom kikkert og manuell modus 
var, men fant det ut ved å teste den.» 

Hva tenkte du om registreringsflyten for sauer? 

«Jeg sytes den var logisk, men jeg likte ikke at jeg måtte skrive inn i feltene for å 
registrere antall sauer. Det var enklere å bruke kikkertmodus i denne prototypen, 
men det var ikke logisk å måtte klikke på den store knappen i stedet for å kunne 
sveipe til høyre og venstre.» 


Test subjekt 2: 


EN 


Hva tenkte du om flyten i applikasjonen? 


«Jeg syntes at den var forbedret og grei å bruke. Det var litt vanskelig å skjønne 
hvordan man byttet mellom kikkertmodus og manuell modus men etter jeg 
skjønte hva knappen gjorde så gikk det fint.» 

Var det noen knapper du var usikker på hva gjorde? 

«Ja som sakt så var det litt vanskelig å skjønne hvordan man byttet mellom 
kikkermodus og manuell registrering. Men jeg syntes det gikk fint etter at jeg 
testet den.» 

Hva tenkte du om registreringsflyten for sauer? 

«Jeg syntes den var bra. Jeg fikk registrert det jeg ville.» 


Test subjekt 3: 


T, 


2. 


Hva tenkte du om flyten i applikasjonen? 

«Flyten var bra, har ikke noe å klage på.» 

Var det noen knapper du var usikker på hva gjorde? 

«Nei, syntes at det var greit.» 

Hva tenkte du om registreringsflyten for sauer? 

«Jeg syntes det var bra, likte ikke at jeg måtte skrive inn antall sauer. Syntes det 
var unødvendig når det bare var en eller to.» 


K, Spørsmål og svar, 
Figma prototype 2 Mobilapplikasjon 


Oppgavene under skal løses under andre testing av Figmaprototypen: 


11. Du er en bonde som nettopp har fått tilgang til dette systemet. Du er medlem av 
et beitelag som inkluderer tre gårder og 5 oppsynspersoner. Opprett en gruppe 
for beitelaget og legg til en av gårdene med blå farge og en av oppsynspersonene. 

12. Du skal ut på en oppsynsrunde for beitelaget. Start en ny oppsynstur for 
beitelaget ved navn Drangedalsgruppa. 

13. Du ser en flokk og plasserer den på kartet. (venter på gjennomføring) 
Saueflokken flyttet seg mens du så på kartet. Registrer posisjonen til flokken. 

14. Ute på oppsynsturen observerer du en flokk sauer. Sauene er ganske langt unna 
og du er nødt til å benytte kikkert for å se dem. Registrer denne flokken mens du 
benytter kikkert for å se dem. (Instruert til å registrere uten å se på telefonen og 
får lest opp 2 sorte sauer og 2 sorte lam) 

15. Fortsatt ute på oppsynsturen observerer du en ny flokk ganske nær deg. Registrer 
en ny flokk med 3 brune sauer med blå merker, hvor en av dem har et gult slips 
og den andre har rødt slips. I tillegg ser du 1 grått lam med blått merke. Legg til 
et bilde av flokken. 

16. Etter dette ser du en ny flokk, men denne er langt unna. Du ser ikke fargen på 
sauen, men du ser at det er 5 av dem. Registrer denne flokken. 

17. På turen observerer du et rovdyr. Registrer dette funnet og legg til et bilde og 
avslutt deretter turen. 


Spørsmål stilt i etterkant av brukertesten: 
Domeneekspert: 


6. Hva var opplevelsen din av applikasjonen? 
«Den oppleves god, jeg synes det flyter godt og at strukturen er logisk, men det 
virker som at det ikke er noen måte å komme seg ut av registrering av en flokk 
på kartet om man har klikket for å plassere den. I tillegg er det kanskje ikke 
meningsfylt å la beiteområde være et eget konsept. Hver oppsynsperson bør 
kanskje få velge sitt eget kartutsnitt å gå etter.» 

7. Var det noe du følte du savnet eller lette etter underveis? 
«Nei, jeg synes at det meste er dekket.» 

8. Hva tenkte du om registreringsflyten for sauer? 
«Jeg synes at knappene man trykker på for å øke eller minke antall sau man 
registrerer er litt små, og de kan godt bli litt større for at det skal være lettere å 
treffe dem når man er ute på tur eller beveger seg.» 


Test subjekt 1: 


1. Hva var opplevelsen din av applikasjonen? 
«Oppleves bra, men litt usikker på hva beiteområde egentlig er.» 

2. Var det noe du følte du savnet eller lette etter underveis? 
«Kanskje kartet på start tur skjermen kunne vært litt større siden det nå ikke 
fyller skjermen. Det kunne også kanskje vært fint å kunne legge til en kommentar 
på en sau og ikke bare på flokken.» 

3. Hva tenkte du om registreringsflyten for sauer? 


«Jeg synes det var bedre med knapper, det føltes bedre å klikke enn å skrive inn 
antall.» 


Test subjekt 2: 


1. Hva var opplevelsen din av applikasjonen? 
«Jeg synes det så bra ut.» 
2. Var det noe du følte du savnet eller lette etter underveis? 
«Jeg tenkte på at jeg ikke kunne se hvilken gruppe jeg gikk for under 
informasjonen i menyen på en tur. Jeg tenkte også på at hvis det er en skadet 
sau ville jeg kanskje hatt lyst til å registrere det direkte i flokken eller på en sau.» 
3. Hva tenkte du om registreringsflyten for sauer? 
«Jeg synes den fungerte bra.» 


Test subjekt 3: 


1. Hva var opplevelsen din av applikasjonen? 
«Bra, men kom meg ikke ut av registreringsmoduls når jeg prøvde etter at jeg 
skulle flytte en flokks posisjon i kartet.» 

2. Var det noe du følte du savnet eller lette etter underveis? 
«Nei ikke egentlig. » 

3. Hva tenkte du om registreringsflyten for sauer? 
«Jeg likte knappene for å legge til sau bedre enn å skrive inn tall. Ellers var det 
bra og det var gøy å kunne legge til bilder.» 


L. Papirprototype Mobilapplikasjon 


Beitegrupper skjerm Start tur skjerm 


| 
å 


Skjerm under tur med kart Kikkertmodus for Registreringsprosessen i 
for registrering av flokker registrering av flokk kikkertmodus 
og meny for registrering av 

hendelser 


Manuellmodus for 
registrering av flokk 


M.Figmaprototype Mobilapplikasjon 


Aktivitetslogg Beitegrupper Profil 


Ø Dalføret Dalføret D Petter Hansen 
3 gårder, 9 oppsynspersoner 
Kart 12.09.21 å Rød gård, Gul gård, Blå gård 
Rød Gård - Per Stålesen 


Tregrensa 
2 gårder, 4 oppsynspersoner 


Tregrensa 
09.08.21 Mine instillinger 
Gul Gård - Jan Johansen 


Dalføret Mine turer 


05.08.21 
Blå Gård - Truls Nilsen 


Mine kart 


Dalføret 
09.07.21 
Rød Gård - Svein Petter Olsen Mine invitasjoner 


Tregrensa 
06.07.21 
Brun Gård - Rita Rønning 
+ LOGG UT 
AV; ÅR fn W EE Beit MW p Å 
Beitegrupper Beitegrupper rofile U elteg rofile 
Hjem skjerm med siste Beitegrupper skjerm med Brukerens profil skjerm 

aktiviteter brukerens grupper 


Siste aktivitet Beitegruppe Dalføret 


Ø& palføret 
Kart 12.09.21 Beiteområde Vestre område 
Rød Gård - Per Stålesen 


Obs, kart er ikke 


Ø balføret Last ned kart over beiteområde 
nedlastet 


Kart 12.09.21 


Rød Gård - Per Ståleser 


Raudbergstjønne 
ON — 


Ø palteøret 
Kart 12.09.21 


Rød Gård - Per Stålesen 


Statistikk 


Døde sau 5 Turer gjennomført 


IQ 


I 
EET 


Skadde sau: 10 Sauer sett 


Medlemmer 
Per Stålesen Rød Gård Admin 
Kristian Aasen Grønn Gård Bruker 


Kari Johansen Blå Gård Bruker 


Gårder 


Oversikt over innholdet i en Startskjermen for en Skjermen for SR startet 


beitegruppe oppsynstur tur med kart og knapp for 
registrering av flokker 


Vis historisk data Vestre område 17.08.21 


Tid brukt: 2t 44m 235 
Distanse: 11km 


07.08.21 Per Stålesen 


Velg kategori 


01.08.21 Truls Nilsen 


Legg til kommentar/notat 


(8) ta bilde 


20.07.21 Svein Petter Olsen 


Legg til hendelse 
JE steg Le 


13.07.21 Trine Helgesen 


01.07.21 Per Stålesen 


7 Klokkeslett 
13:23:44 


7 Posisjon 
62"14'52.75027" N 9*5826.64124" Ø A 


7 Fullfør tur 


G> Avbryt tur 2) Lapre 


Meny for å vise eldre turer i Meny for oversikt over info Skjermen for registrering 
kartet om turen, registrerte av en hendelse 
hendelser og mulighet for 
å fullføre/avslutte tur 


Antall dyr Antall dyr 


1 Grå $au 2 Grå lam 


0 Grå sau | 0 Grå lam 


: å T Brun sau 0 Brunt lam 
| OBrun sau | O Brunt lam 


1 Sort sau 0 Sort lam 
0 Sort sau | 0 Sort lam 


L BENGT 
N egistrer 
; TT == 
Knappen som vises etter Kikkertmodus for Slutten av 
man har plassert en flokk i registrering av flokker registreringsflyten for 


kartet. kikkertmodus 


Avbryt registrering Avbryt registrering 


Antall dyr 


Antall dyr 


Registrer mer info 


1 SAU-GRÅ 

(9 Legg til bilde 
Tag Rød Slips Rød 

Legg til kommentar 


2 LAM-GRÅ 


Tag Rød 


3 LAM-GRÅ 


Tag Rød 


Manuell registrering etter 

redesign av input feltene. 

Her vist uten noen sauer 
registrert 


4 SAU - BRUN 


Tag Blå Slips | Blå 


5 SAU- SORT 


Tag Grønn Slips Blå 


OBS! Det mangler 1 lam i denne flokken etter registrerte 
opplysninger. Etterse at antall lam og fargen på slips 
stemmer. 


19 Legg til bilde 


Legg til kommentar 


Oversikt over manuell 
registrering av en flokk 


Antall lam 


4 


Klokkeslett 


10:03 


Kommentar 


Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed 
do elusmod tempar incksdunt ut labore et dolsre magna 
aliqua. Ut enim ad minim venlam, quis nostrud exercitation 
ullameo laboris nisi ut aliquip ex eå commado consequat. 


Duis aute sure dokor in reprehenderit in voluptate velit esse 
eillum dolore eu fugiat nulla parfåtur. Excepteur sint occaerat 
cupidatat non proident, sunt in cupa qui officia deserunt. 


Dyr 


tamt 
Brun * Røed Gård 


Lam2 


Grå - Apod Gård 


um 


5011 + Østre Vettre 


Lam 4 


Grå - Østre Vettre 


Sau I * Skadet 


Ge * Øatre Ventre - Stigs 


Sau2 


Sant + Østre Vettre 


Sau3 


Brun » Østre Vertre - Spa: 


Sau 


Grå - Østre Vettre 


Sau 5 


Grå - Røed Gård - Sps: Ingen 


Sm 


Sort * Røed Gård - 


Sau? 
Sort * Røed Gård - Sips: Rød 


Oversikt over en fullført 
tur 


N. Figma navigasjonsstruktur, 


Mobilapplikasjon 


sa 


Flow Flow53 [ Flow9 p> 21 [> 


Tur 58 T 
Flow27 |>33 bi ruw20 > 
> y PAR, 


———- 
Flow: Flow 45 [> 


mw) DO 


Fovs2 > — 


Flow49 D Flow54 [> 


Flow Flow56 [> Flowi Flow3 Flow31 [> : Flow36 > 37 > 38 > 


" 
ET EE NE 
&A KK ANE: 
= 
” 


Flow: Flow4 Flow41 [> 42 D 


” 

pr Æ == ER 
HanA 
Flow Flowt "ra" Fic 1 Fow1 Flow1 Flow1 Flovz1 Fow1 Flow1 Flow 19 [> 


* - hå å 
Å å . ; ; . - 
Fioe I owi Fwit wie | fr 


O. Figmaprototype Webapplikasjon 


k Dashbord 
å 
G Sesong 2022 GrazingGroup 1 vw 
dale! Døde sauer Turer gått Rovdyr sett Skadde sauer Gårder 


dD 9) 2) 2 2 å Røed Gård 


Dashbord Å Frøysa Gård 
En! Årets turer Å Rælingen Gård 
Rapporter Dato Oppsynsperson Sauer sett Hendelser 
å Rygge Gård 
04.01.2022 Ted Hansen 14 va 
Medlemmer 
20.01.2022 Kim Tronsen 18 va 
ka» 
(08) Ted Hansen 
02.02.2022 Åge Normann 23 vw 
KJÆR 
Kim Tronsen 
05.02.2022 Tore Fransen 32 va 
ST 
8) Åge Normann 
24.02.2022 Kim Tronsen 4 pg 
FEG 


Tore Fransen 
17.03.2022 Ken Yee 23 Aa 


ka 
01.04.2022 Åge Normann 16 (08) Ken Yee 


Profil 


Forsiden av webapplikasjonen når bruker er innlogget. Viser informasjon om en valgt 
beitegruppe. 


GrazingGroup 1 
Ted Hansen - 04.01.2022 


Distanse Tid Antall sau Antall lam Hendelser Skadde sau Flokker w 
23.34 km 4t 23m 83 43 7 2 Flokk 1 


Flokk 2 
7 sau * 4 lam - kl 10:03 


Flokk 3 
7 sau * 4 lam - kl 10:03 


Flokk 4 
7 sau + 4 lam - kl 10:03 


Flokk 5 
7 sau * 4 lam - kl 10:03 


Vis flere 
Hendelser 
Hendelse tittel 1 
Dødt dyr - kl 10:03 


Hendelse tittel 2 
Rovdyr - kl 10:03 


Hendelse tittel 3 
Notat - kl 10:03 


rønbakkhøe 


SH 


o— Å Knutsho 


Flokk 1 Dyr 
Antall sau Antall lam Sau1 +55 Lam 1 
Få 4 «Brun —» Røed Gård —» Grønt silps «Sort» Røed Gård 
Sau 2 [3] Lam 1 
Skader Klokkeslett 
«Grå — + Røed Gård —» Grønt slips «Sort — + Røed Gård 
1 10:03 
Sau1 +G5 Lam 1 
«Brun» Røed Gård» Grønt slips «Sort — + Røed Gård 
Kommen 
føfem ipsum dolor sit amet, consectetur adipiscing 
elt, sed do eiusmod tempor incididunt ut labore et 2 E) tamt 
dolore magna aliqua. Ut enim ad minim veniam, «Grå —+ Røed Gård —» Grønt slips «Sort —+ Røed Gård 
quis nostrud exercitation ullamco laboris nisi ut 
aliquip ex ea commodo consequat 


Oversikten over en tur med detaljer. 


Rapport 


PE 


Ted Hansen Beitegruppe: Beitegruppe | V 


Sesong: Sesong v 


di 


Rapporter 


Profil 


Side for valg av rapportdata 


Generert 26.05.2022 
av Odd Larsen 


Oppsynsrapport utmarksbeite 
Sesong 2022 


Odd Larsen 
Ted Hansen 
Metadata 
Tilsyn gjennomført I beitelag? Ja 
da Deltakende gårder 3 
Oppsynspersoner 5 
Dashbord 
Tid brukt på oppsyn 25.51 
Oppsynsturer gjennomført v 
(an) Oppsummering 
Rapporter Sauer observer Ja 
Funn av døde dyr: 3 
Observasjoner av rovdyr 5 
Turer: 
Tur 1 Avvik/Merknad 
Dato 26/05/2022 
Oppsynsperson Odd Larsen 
Tid brukt at 
Flokker sett 5 
| Flokk 1 Sett kl Sau Lam Posisjon 
1 0525 2 å 1234 


Q 


Profil 


Generert rapport 


P. Spørsmål og svar, Figma prototype 
Webapplikasjon 


Oppgavene under skal løses under testing av Figmaprototypen av Webapplikasjonen: 


18. 


19. 


20. 


21. 


Du er en bonde som nettopp har fått tilgang til dette systemet. Du er blitt invitert 
til en beitegruppe og har akseptert invitasjonen. Finn ut hvor mange turer som er 
blitt gått i Oppdalsgruppa så langt i sesongen. 

Du har gjennomført en oppsynsrunde og ønsker å se at informasjonen du har 
registrert er riktig. Aksesser den siste turen du gjennomførte og sjekk at antallet 
flokker registrert er 3. 

Under turen som ble gjennomført ble det registrert en hendelse. Inspiser bildet 
som ble tatt i løpet av denne hendelsen og finn ut hva som skjedde. 

Generer en rapport over beitesesongen så langt. 


Spørsmål stilt i etterkant av brukertesten: 


Domeneekspert: 


LE Å 


10. 


11. 


Hva var opplevelsen din av applikasjonen? 

«Den var veldig bra, syntes det var logisk å navigere seg gjennom. Enkelt å finne 
frem til hva man ville se på.» 

Var det noe du følte du savnet av informasjon? 

«Jeg savnet en linje mellom registreringspunkt i kartet og flokken man 
registrerte. I tillegg hadde det vært veldig fint å kunne se beitekvalitet i kartet. 
Det er veldig nyttig for bøndene å vite om.» 

Hva tenkte du om oversikten over en gjennomført tur? 

«Syntes den var oversiktlig og fin. Man får all den informasjonen man trenger 
der.» 


Test subjekt 1: 


Zi 


Hva var opplevelsen din av applikasjonen? 

«Overall bra flyt. Kanskje man kunne hatt en dropdown for å velge sesonger også 
sånn som med beitegrupper i stedet for å få opp alle turer på en skjem om man 
trykker tidligere sesonger?» 

Var det noe du følte du savnet av informasjon? 

«Jeg syntes det var bra med informasjon, men jeg synes kanskje det kunne vært 
en oversikt over hva de forskjellige tingene markert i kartet betyr.» 

Hva tenkte du om oversikten over en gjennomført tur? 

«Syntes den var ryddig og oversiktlig.» 


Test subjekt 2: 


1. 


2. 


Hva var opplevelsen din av applikasjonen? 

«Jeg likte sidemenyen og at alt var tilgjengelig derfra.» 

Var det noe du følte du savnet av informasjon? 

«Jeg synes at det kunne vært forklart hva de forskjellige ikonene i kartet er. Sau 
er jo greit, men det kan jo være fint å kunne trykke på dem og se info om dem 
også.» 

Hva tenkte du om oversikten over en gjennomført tur? 


«Syntes den var fin og oversiktlig.» 
Test subjekt 3: 


1. Hva var opplevelsen din av applikasjonen? 
«Syntes det fungerte bra, det var veldig lett å produsere rapport så det var veldig 
bra. Kanskje litt vanskelig å skille mellom hva som var knapper og ikke.» 
2. Var det noe du følte du savnet av informasjon? 
«Nei, jeg synes alt så bra ut.» 
3. Hva tenkte du om oversikten over en gjennomført tur? 
«Synes den var bra, kunne kanskje hatt litt større overskrifter.» 
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R. Suksesskriterieanalyse 


Suksesskriterieanalyse av WCAG 2.0 
Nummer | Kategori Kriterie Grad av oppfyllelse 
1.1.1 A Ikke-tekstlig 
innhold 
1.2.1 A Bare lyd og bare 
video 
1.2.2 A Teksting 
1.3.1 A Informasjon og 
relasjoner 
1.3.2 A Meningsfylt 
rekkefølge 


6 1.3.3 A Sensoriske All data i mobil og web appen er 
egenskaper forklart med tekst eller i 
kombinasjon med ikoner og farge. 
Det eneste området hvor dette 
avviker er områdene nevnt i punkt 
al galgat 

7 1.4.1 A Bruk av farge Ingen informasjon i appen er kun 
indikert eller formidlet ved hjelp 
av farge. All fargekoding er 
supplerende til tekstlige eller 
andre visuelle beskrivelser. 

8 1.4.2 A Styring av lyd Brukeren har mulighet til å skru 
ned lyden på talemeldinger som 
leses opp i mobilapplikasjonen ved 
å bruke mobilens innebygde 
funksjonalitet. Brukeren har også 
muligheten til å registrere sauer i 
manuell modus for å ikke høre 
talemeldinger. 

9 1.4.3 AA Kontrast 

10 1.4.4 AA Endring av Deler av mobilapplikasjonen tåler 

tekststørrelse ikke forstørrelse opp til 200% 
størrelse. Dette er noe som må 
utbedres. 

11 1.4.5 AA Bilder av tekst Det er ingen bilder av tekst i mobil 
eller webapplikasjonen 

12 2.1.1 A Tastatur All funksjonalitet i 
webapplikasjonen er tilgjengelig 
via navigasjon med tastatur 

13 2.1.2 A Ingen tastaturfelle | Det er ingen tastaturfeller i 
webapplikasjonen 

14 2.2.1 A Justerbar Det finnes ingen 

hastighet tidsbegrensninger i mobil eller 
web applikasjon 

15 2.2.2 A Pause, stopp skjul | Det finnes ikke noe innhold i mobil 
eller webapplikasjonen som 
endrer seg automatisk. 

16 2.3.1 A Terskelverdi på Det er ingenting i mobil eller web 

maksimalt tre appen som blinker 
glimt 

17 2.4.1 A Hoppe over Brukere kan per i dag ikke hoppe 

blokker til hovedinnholdet ved tabbing. 

18 24.2 A Sidetitler Alle sider i både web og 
mobilapplikasjonen har tydelige 
sidetitler som beskriver innholdet 
på siden. 

19 2.4.3 A Fokusrekkefølge Innholdet på websiden blir 


presentert i en logisk rekkefølge 
for brukeren. Både i mobil og 


webapp er innholdet sortert etter 
nytte og nyligst registrert info. 


20 


2.4.4 


Formål med lenke 


Det finnes ingen lenker ut av 
applikasjonen hverken i web eller 
mobilapplikasjonen. 


21 


2.4.5 


AA 


Flere måter å 
navigere på 


Per i dag er menyen i web 
applikasjonen den eneste måten å 
navigere i applikasjonen på. Dette 
er noe som må utbedres ved for 
eksempel et nettstedkart. 


22 


23 


2.4.6 


2.4.7 


AA 


AA 


Overskrifter og 
ledetekster 


Synlig fokus 


Alle ledetekster og overskrifter i 
både mobil og web applikasjonen 
er beskrivende og beskriver 
funksjonalitet eller informasjon 
som finnes under 

Alt innhold på web siden får synlig 
fokus når en bruker navigerer 
med tastatur 


24 


3.1.1 


Språk på siden 


Språk for web applikasjonen er 
angitt i index html. 


25 


3.1.2 


AA 


Språk på deler av 
siden 


Ingen deler av web eller mobil 
applikasjonen er på andre språk 
enn Norsk 


26 


3.2.1 


Fokus 


Ingen elementer som får fokus i 
mobil eller web applikasjonen 
medfører betydelige endringer på 
siden 


27 


3.2.2 


Inndata 


Ingen endring av verdier i 
skjemafelter medfører store 
endringer i brukergrensesnittet 
hverken i mobil eller 
webapplikasjonen 


28 


3.2.3 


AA 


Konsekvent 
navigering 


I mobil applikasjonen vil 
navigasjonsmenyen alltid forbli i 
samme rekkefølge og 
tilbakepilene i topp menyen vil 
alltid vises på samme sted. I 
webapplikasjonen vil 
navigasjonsmenyen alltid ha 
samme rekkefølge. Ingen andre 
navigasjonselementer gjentas 
over flere sider. 


29 


3.2.4 


AA 


Konsekvent 
identifikasjon 


Alle knapper i mobil og web 
applikasjonen har samme uttrykk 
for å møte brukernes 
forventninger. 


30 


3.3.1 


Identifikasjon av 
feil 


Hvor skjemaer viser feilmeldinger 
vises feilmeldingen under det 
relevante feltet slik at brukeren 


31 33.2 Ledetekster eller 
instruksjoner 

32 3.3.3 Forslag ved feil 

33 3.3.4 Forhindring av feil 

34 4.1.1 Parsing 

35 4.1.2 Navn, rolle, verdi 


S. Systemtest 


Krav 


Utført Kommentar 


En bruker skal kunne 
opprette en profil for å 
benytte systemet 


En bruker med profil skal 
kunne aksessere systemet 
med sin epost og passord 


En bruker skal kunne slette 
sin profil 


En bruker skal kunne endre 
sin profilinformasjon 


En bruker skal kunne se de 
nyeste turene som er blitt 
gjennomført 


En bruker skal kunne 
aksessere eldre turer og se 
detaljer om turen 


En bruker skal kunne 
opprette ny beitegruppe 


En bruker skal kunne 
opprette gårder i 
beitegruppen 


En bruker skal kunne legge 
til medlemmer i gruppen 


En bruker skal kunne godta 
en invitasjon til en 
beitegruppe 


En bruker skal kunne 
aksessere sine 
beitegrupper og se turer 
gjennomført i gruppen 


En bruker skal kunne 
administrere gruppen om 
brukeren er administrator 


En bruker skal kunne starte 
en ny oppsynstur 


En bruker skal kunne laste 
ned et kartutsnitt for bruk 
uten internett 


Funksjonelle krav 


Mobilapplikasjon 


Per i dag slettes brukeren 
med all relevant data de 
har registrert. Optimalt kan 
brukeren slettes, og 
oppsynsdataen kan 
beholdes anonymisert 


En bruker skal kunne 

registrere flokker sett med 
passende detaljnivå basert 
på hvor mye brukeren ser 


En bruker skal kunne 
registrere hendelser på en 
oppsynstur slik som syn av 
rovdyr 


En bruker skal kunne se en 
oversikt over turen når 
turen er gjennomført 


En bruker skal kunne 
opprette en profil for å 
benytte systemet 


En bruker med profil skal 
kunne aksessere systemet 
med sin epost og passord 


En bruker skal kunne slette 
sin profil 


En bruker skal kunne endre 
sin profilinformasjon 


En bruker skal kunne se 
detaljer om turen etter 
fullført tur 


En bruker skal kunne se 
beitekvaliteten i 
beiteområdet i kartet 


En bruker skal kunne 
generere rapporter basert 
på beitesesongen i 
standardisert format 


Raskere å generere 
rapporter enn ved manuell 
opprettelse 


Enklere å finne 
beitedata/dyredata om din 
gård enn uten systemet 


Raskt å laste inn data 


Webapplikasjon 


Ikke funksjonelle 


Per i dag slettes brukeren 
med all relevant data de 
har registrert. Optimalt kan 
brukeren slettes, og 
oppsynsdataen kan 
beholdes anonymisert 


Målt gjennom 
sammenligningstest 


Målt ved samtale med 
domeneekspert 


Under 1 sekund for 
innlasting av data og 
visning av alle sider i 
applikasjonen 


Følger gjeldende lover og 
regler angående 
personvern og GDPR 


Lagring gjennomføres på 
under 2 sekunder lokalt og 
på under 10 sekunder til 
skyen. 


Data lagres sikkert og 
effektivt 


TF 


Spørsmål og svar Endelig brukertest av 
systemet 


Spørsmål og svar, Mobilapplikasjon 


Oppgavene under skal løses under testing av Mobilapplikasjonen: 


Generell Applikasjonsfunksjonalitet: 


22. 


Du har nettopp fått tilgang til applikasjonen. Opprett en bruker og logg inn. 


Domenespesifikk applikasjonsfunksjonalitet: 


23. 


24. 


25. 
26. 


27. 


Ute 


28. 


29. 


30. 


31. 


32. 


Du er en bonde som nettopp har fått tilgang til dette systemet. Du er medlem av 
et beitelag som inkluderer 3 gårder og 5 oppsynspersoner. Opprett en gruppe for 
beitelaget og legg til en av gårdene og en av oppsynspersonene. Gi denne 
personen admin rettigheter. 

Du har blitt invitert til beitegruppen Oppdalsgruppa, Aksepter invitasjonen og finn 
ut hvor mange gårder som er med i gruppen. 

Finn ut hvor mange rovdyr som ble sett på den forrige turen i gruppen. 

Du skal ut på en oppsynsrunde for beitelaget. Start en ny oppsynstur for 
beitelaget ved navn Oppdalsgruppa. 

Du lurer på hvor den forrige oppsynspersonen gikk tur, Vis den forrige turen som 
ble gjennomført i kartet. 


Ute på oppsynsturen observerer du en flokk sauer. Sauene er ganske langt unna 
og du er nødt til å benytte kikkert for å se dem. Registrer denne flokken mens du 
benytter kikkert for å se dem. (Instruert til å registrere uten å se på telefonen og 
får lest opp 1 brun sau og 3 brune lam) 

Fortsatt ute på oppsynsturen observerer du en ny flokk ganske nær deg. Registrer 
en ny flokk med 2 grå sauer med røde merker, hvor en av dem har et grønt slips 
og den andre har gult slips. I tillegg ser du 3 grå lam med røde merker. 

Den neste flokken du kommer over har 6 dyr. Sauene vises til testsubjektet. (1 
Grå sau med rødt slips, 1 Grå sau med blått slips, 1 Brun sau med gult slips. 3 
lam. Alle med blå øremerker.) Det ene lammet ser ut til å ha en skade på venstre 
frembein. Registrer dette. 

På turen observerer du et dødt dyr. Registrer dette funnet med bildebevis og 
avslutt deretter turen. 

Når du kommer tilbake, vil du laste opp truen. Gjør dette. 


Spørsmål stilt i etterkant av brukertesten: 


Domeneekspert: 


6. 


7. 


Hva tenkte du om flyten i applikasjonen? 

«Veldig bra, den har all funksjonaliteten som er nødvendig og det er tydelig 
gjennomtenkt. Jeg synes det var enkelt å finne frem utenom at jeg ikke er helt 
vant til mønsteret med disse runde knappene. Men det var greit å finne ut 
hvordan det fungerte.» 

Var det noen knapper du var usikker på hva gjorde? 


«Jeg slet litt med en gang å se forskjell på den runde knappen på hjem skjermen 
og den som er på beitegruppesiden. Men jeg ser nå at de har forskjellige ikoner 
og det gir mening at de gjør forskjellige ting.» 

Hva tenkte du om registreringsflyten for sauer? 

«Jeg syntes den var helt topp. Liker veldig godt at det er talemeldinger til 
brukeren i kikkertmodus og at man får opp kikkertmodus eller manuell modus 
avhengig av hvor nære en flokk man er.» 

Har du noen andre tilbakemeldinger? 

«Jeg synes at appen fungerer veldig bra, og jeg syntes det gikk veldig bra å 
navigere og finne frem til det jeg ønsket å se.» 


Test subjekt 1: 


1. 


Hva tenkte du om flyten i applikasjonen? 

«Veldig enkel og grei å forstå med tanke på at det er føste gang jeg har brukt 
applikasjonen.» 

Var det noen knapper du var usikker på hva gjorde? 

«Jeg var usikker på om det var nødvendig å laste ned kartet for å kunne starte en 
tur.» 

Hva tenkte du om registreringsflyten for sauer? 

«Registreringsprosessen var veldig enkel og grei å forstå. Jeg hadde litt problemer 
med å skjønne hvilken vei jeg skulle sveipe knappen for å legge til eller fjerne 
sauer i kikkertmodus, men jeg skjønte det etter litt testing. Det var også litt 
forvirrende at det var et eget felt for totalt antall sauer. Jeg trodde jeg måtte fylle 
ut dette først.» 

Har du noen andre tilbakemeldinger? 

«Det var litt vanskelig å se hvilket element som var aktivt ved å se på dem i 
kikkermodus. De kunne vært litt tydeligere.» 


Test subjekt 2: 


1. 


Hva tenkte du om flyten i applikasjonen? 

«Jeg synes flyten er god, og jeg likte at jeg alltid kunne finne viktig funksjonalitet 
på de runde knappene som kom til syne på de forskjellige sidene. Jeg ble litt 
usikker på flyten inne på start tur siden jeg ikke visste om jeg var nødt til å laste 
ned kart. Men siden det var den eneste knappen der tenkte jeg at jeg skulle teste 
det.» 

Var det noen knapper du var usikker på hva gjorde? 

«Jeg syntes også at det kanskje hadde gitt mening å ha et pluss tegn ved siden 
av kartet på knappen på forsiden siden jeg først trodde at det bare var en knapp 
for å se på kartet.» 

Hva tenkte du om registreringsflyten for Sauer? 

«Registreringsflyten fungerte veldig bra, og jeg likte å kunne legge til og fjerne 
sauer på en veldig enkel måte.» 

Har du noen andre tilbakemeldinger? 

«Nei, jeg syntes registreringen fungerte veldig bra.» 


Test subjekt 3: 


1. 


Hva tenkte du om flyten i applikasjonen? 


«Det var logisk, og jeg fant frem til det jeg skulle. Det var kanskje litt vanskelig å 
finne ut hvor turene havnet etter jeg hadde gjennomført dem. Jeg forventet at 
den skulle vises i feed'en med en gang, men den måtte lastes opp via profil først, 
så det var litt vanskelig å skjønne med en gang.» 

Var det noen knapper du var usikker på hva gjorde? 

«Jeg syntes at tannhjulet øverst i hjørnet under en tur ikke var helt intuitivt for 
hva som skjulte seg bak der. Gamle turer ville jeg forventet at hadde et annet 
ikon selv om jeg ikke vet hvilket.» 

Hva tenkte du om registreringsflyten for sauer? 

«Registreringsflyten fungerte veldig bra, selv om jeg ble litt forvirret av totalt 
antall sauer i kikkertmodus.» 

Har du noen andre tilbakemeldinger? 

«Nei, jeg syntes det fungerte bra og var lett å bruke.» 


Spørsmål og svar, Webapplikasjon 


Oppgavene under skal løses under testing av Webapplikasjonen: 


Generell Applikasjonsfunksjonalitet: 


1. 


Du har nettopp fått tilgang til applikasjonen. Opprett en bruker og logg inn. 


Domenespesifikk applikasjonsfunksjonalitet: 


2. 
3. 
4. 


5. 
6. 


Aksesser Oppdalsgruppa og identifiser hvor mange turer som er gjennomført 
denne sesongen. 

Se data om turen du gjennomførte. Sjekk om informasjonen du registrerte er 
korrekt. 

Inspiser bildet du tok av det døde dyret. 

Finn ut hvilken beitekvalitet det er mest av i Oppdal. 

Generer en rapport over beitesesongen så langt. 


Spørsmål stilt i etterkant av brukertesten: 


Domeneekspert: 


Lå 


Hva tenkte du om flyten i applikasjonen? 

«Veldig enkel å følge. Jeg ble litt forvirret av hvor man kunne endre beitegrupper 
og at dette ble hentet inn med en gang uten at jeg behøvde å klikke på noen 
ekstra knapp.» 

Var det noen knapper du var usikker på hva gjorde? 

«Nei alt var veldig logisk der.» 

Hva tenkte du om oversikten over en tur? 

«Veldig ryddig og fint, fikk all informasjon jeg trengte.» 

Har du noen andre tilbakemeldinger? 

«Nei, jeg syntes dette var en kjempe applikasjon. Og at man kan se bilder i 
rapporten er ikke engang noe som har falt meg inn.» 


Test subjekt 1: 


1. Hva tenkte du om flyten i applikasjonen? 
«Det var veldig enkelt å finne frem. Alt fantes tilgjengelig fra Dashbordet.» 
2. Var det noen knapper du var usikker på hva gjorde? 
«Nei, syntes alt var veldig enkelt å forstå.» 
3. Hva tenkte du om oversikten over en tur? 
«Enkel og grei oversikt, ikke noe å klage på.» 
4. Har du noen andre tilbakemeldinger? 
«Nei egentlig ikke.» 


Test subjekt 2: 


1. Hva tenkte du om flyten i applikasjonen? 
«Veldig grei struktur, det var enkelt å komme seg rundt. Ingenting som var 
forvirrende i strukturen.» 

2. Var det noen knapper du var usikker på hva gjorde? 
«Nei, syntes det fungerte veldig bra.» 

3. Hva tenkte du om oversikten over en tur? 
«Veldig bra, var gøy å kunne se alle sauene man hadde registrert og at bilde kom 
opp på hendelsen man registrerte i applikasjonen.» 

4. Har du noen andre tilbakemeldinger? 
«Nei.» 


Test subjekt 3: 


1. Hva tenkte du om flyten i applikasjonen? 
«Synes det var ålreit, ikke noe forvirrende siden man alltid har menyen 
tilgjengelig på venstre side. Også var det bra at man kunne gå tilbake med 
navigeringsknappen i browser.» 

2. Var det noen knapper du var usikker på hva gjorde? 
«nei, alt var forklart med tekst så syntes det var ok.» 

5. Hva tenkte du om oversikten over en tur? 
«Den var veldig fin, syntes det var gøy å se info om beitekvalitet komme frem. 
Veldig interessant egentlig, og litt moro å se rundt i landet. I tillegg var det veldig 
fint å kunne klikke på ikonene og få mer info om flokken. Kanskje flokken i 
sidemenyen kunne blitt «highlightet» når den er valgt eller når man klikker på en 
flokk i kartet?» 

3. Har du noen andre tilbakemeldinger? 
«Nei, syntes det virket veldig bra.» 


ØNTNU 


Kunnskap for en bedre verden 


